Why seperate Message Enqueuer and Dequeuer from the Message Queue Class?

[PrimaryKey]

I have not found a good answer to this and it bugs me when I use actor framework. What is the reason for seperating enqueuer and dequeuer into seperate classes. To me those should be just methods from the queue class. This whould be much more readable.

Why is it done like this. Anyone knows?

[AristosQueue (NI)]

That is discussed in the AF white paper that ships with LV and is available on these forums on the READ THIS FIRST page.

Quoting from that document:

Under the hood, the framework makes extensive use of LabVIEW's queue functions. The public API, however, hide the raw queues using the Message Enqueuer class. This class is a wrapper around LabVIEW's queue references that provides only the ability to enqueue. This means the reference may be shared with other processes without worrying that the other processes are messing with the invariants on which the Actor Framework is predicated. The other processes cannot destroy the queue prematurely, they cannot flush the queue, etc. Message Enqueuer provides four levels of priority enqueue behavior, while maintaining the same high performance for which the LabVIEW queues are known. By limiting what can be done to the queues in various parts of the code, the framework is able to make guarantees about timing and message delivery that otherwise could not be proven.

[AristosQueue (NI)]

> This whould be much more readable.

How would this change the readability of the code in your view? Assuming everyone used only the functions that are allowed in each region of the code, you would still see the same number of references and the same number of subVI calls to the same functions. The only thing that would be different is that we would no longer see "Message Enqueuer" but instead "Message Queue" -- which, to me, would make the code less readable since you would lose the indication of directionality that lets me know "this piece of code is sending data, not receiving it."

I'm curious to hear what you think would be made more readable because we do keep trying to improve the learnability of the AF. Perhaps something can be changed to achieve your readability goals without violating the AF design contracts.

[PrimaryKey]

For me it would be more readable if the enqueuer/dequeuer methods were methods of the queue class but I get the point of the directionality. If i continued the subject then it would change into a dicussion about names and I know you gave those a lot of thought.

Directionality is a good answer for me With my architectures I usually dont care about that because I know the direction of queues.

[AristosQueue (NI)]

Piotr_Kruczkowski wrote:

With my architectures I usually dont care about that because I know the direction of queues.

Ah, but do you remember that directionality a year later when you have to come back to the same project? That's the bugaboo that bites me if I don't have little hints like that. 🙂