Asynchronous Messaging explained as a coffee shop

[AristosQueue (NI)]

This is *great* documentation of the patterns of interaction that Actors in the Actor Framework have with each other. I highly recommend all AF users read this:

http://www.eaipatterns.com/docs/IEEE_Software_Design_2PC.pdf

[EDIT] MattP has developed this verbal description into actual working code using the Actor Framework. The latest evolution of his example is attached here (you can find discussion about it later in the thread).

[AristosQueue (NI)]

There is only one point in the article, at the very end, where I would highlight a slightly different behavior:

The customer, on the other hand, expects a synchronous interaction; he or she came to the store to buy a drink and will have to stay until the drink is delivered. This type of synchronization is fairly common and has been documented as the Half-sync, Half-async pattern.

In the Actor Framework, if both the barista and the customer are actors, then you could design this system with a Reply Msg.lvclass so that the customer is waiting for a reply from the barista. But instead, allow the customer to check his/her cell phone while waiting, or do any number of other tasks (read news paper, talk to friends). The point of the Actor Framework is it lets each actor work on whatever it has to work on. So the customer Actor sends a message to the barista (perhaps using the cachier as a proxy) and then goes off and does its own thing until the customer gets the drink message from the barista. No synchronous waiting needed.

It does require thinking of each actor in your system as wholly independent from the outset, but the payoff is worth it. Independent actors maximize the work each one is able to do and avoid deadlocking waiting for each other (imagine if the customer wasn't going to pay until he got his drink and the barista wasn't going to make the drink until the customer paid).

[Jiri_K]

It would be great to have this example of coffee shop implemented in LV. It is nice to imagine the flow.

[MattP]

I've been looking for an excuse to build a good demonstration using AF - I'll build this and post it here.

[MattP]

Nothing like a back-burner project that gets shelved for a while.

Attached is the first implementation of the coffee shop, written in LV 2012.  I'd love to hear your feedback.

There are still plenty of rough edges and non-finalized bits, but the core functionality works well, and it seems to scale fairly well.

I added a 'work dispatcher' abstraction to handle assigning of tasks from an unknown number of sources to an unknown number of destinations.  It works for things like customers waiting for the next cashier to make an order, and orders waiting for the next available barista to make them.  It may be of use in other projects.

The example also incorporates (steals) the Decorator Pattern example posted here: https://decibel.ni.com/content/docs/DOC-13332

NOTE: Latest version can be found here: https://decibel.ni.com/content/message/50257#50257

[MattP]

AristosQueue wrote:

There is only one point in the article, at the very end, where I would highlight a slightly different behavior:

The customer, on the other hand, expects a synchronous interaction; he or she came to the store to buy a drink and will have to stay until the drink is delivered. This type of synchronization is fairly common and has been documented as the Half-sync, Half-async pattern.

In the Actor Framework, if both the barista and the customer are actors, then you could design this system with a Reply Msg.lvclass so that the customer is waiting for a reply from the barista. But instead, allow the customer to check his/her cell phone while waiting, or do any number of other tasks (read news paper, talk to friends). The point of the Actor Framework is it lets each actor work on whatever it has to work on. So the customer Actor sends a message to the barista (perhaps using the cachier as a proxy) and then goes off and does its own thing until the customer gets the drink message from the barista. No synchronous waiting needed.

It does require thinking of each actor in your system as wholly independent from the outset, but the payoff is worth it. Independent actors maximize the work each one is able to do and avoid deadlocking waiting for each other (imagine if the customer wasn't going to pay until he got his drink and the barista wasn't going to make the drink until the customer paid).

I agreed, and implemented it with customer being independent.  No actor synchronously waits for any other actor.

Also, I deviated from the Starbucks 'barista leaves finished drinks on counter and broadcasts name/order' model and replaced it with the Panera 'customer's pager goes off when item is ready' model.  I dislike broadcast messages.

[Bob_Schor]

Matt,

     I'm very interested!  When I opened the StarBuzz project in LV2012f3, I got the following message:

StarBuzz\Classes\StarBuzz\Actor Core.vi (StarBuzz.lvlib:StarBuzz.lvclass:Actor Core.vi)

LabVIEW:  Attempted to read flattened data of a LabVIEW class.  The data was written by an old version of the class and the class in memory no longer supports loading and mutating data from that older version.  LabVIEW class Actor Framework.lvlib:Actor.lvclass supports versions 1.0.0.3 through 1.0.0.4.  The flattened data is in Version 1.0.0.1.  Your control or constant value has been reset to the class default value.

[I tried to Cut and Paste the message, but couldn't, so I had to type it by hand -- there may be a typo, but the basic error is there ...]

The Launcher (and, I'm sure, other VIs) has a Broken Arrow, complaining about the Actor Class.  Suggestions?

Bob Schor

[MattP]

Bob_Schor wrote:

Matt,

     I'm very interested!  When I opened the StarBuzz project in LV2012f3, I got the following message:

StarBuzz\Classes\StarBuzz\Actor Core.vi (StarBuzz.lvlib:StarBuzz.lvclass:Actor Core.vi)

LabVIEW:  Attempted to read flattened data of a LabVIEW class.  The data was written by an old version of the class and the class in memory no longer supports loading and mutating data from that older version.  LabVIEW class Actor Framework.lvlib:Actor.lvclass supports versions 1.0.0.3 through 1.0.0.4.  The flattened data is in Version 1.0.0.1.  Your control or constant value has been reset to the class default value.

[I tried to Cut and Paste the message, but couldn't, so I had to type it by hand -- there may be a typo, but the basic error is there ...]

The Launcher (and, I'm sure, other VIs) has a Broken Arrow, complaining about the Actor Class.  Suggestions?

Bob Schor

Hi Bob,

The version I posted earlier suffered from some distribution problems (mostly due to my lvlib file forgetting which classes it contained).  The corrected version posted above downloads and runs well on my machine with LV 2012f3.  Can you try again with the corrected version and let me know if it still causes you the same grief?

[Bob_Schor]

I'm home, now, working on my Laptop (also LV 2012f3).  Downloaded the files in Message 4, unzipped to Desktop, then tried to open the Project.  Here is the text file I was able to generate from the Warning Message:

C:\Users\RSchor\Desktop\StarBuzz\Classes\StarBuzz\Actor Core.vi (StarBuzz.lvlib:StarBuzz.lvclass:Actor Core.vi)

    LabVIEW:  Attempted to read flattened data of a LabVIEW class. The data was written by an old version of the class and the class in memory no longer supports loading and mutating data from that older version. LabVIEW class Actor Framework.lvlib:Actor.lvclass supports versions 1.0.0.3 through 1.0.0.4. The flattened data is in version 1.0.0.1. Your control or constant value has been reset to the class default value.

I'm happy to "play" and try to manually "fix" the class, but I'm not sure how to proceed.  Incidently, I'm running 32-bit LabVIEW on 64-bit Windows 7 Pro.

BS

[Bob_Schor]

Hey!  After sending the previous e-mail, I closed LabVIEW, which did a lot of "saving" of the StarBuzz files.  On a hunch, I opened it again -- no error this time, and when I open the Launcher, the Run Arrow is not broken!  Maybe it fixed itself?  I'm going to play around, will try to get back (maybe not today) with my experience.

Thanks, Matt!

BS