Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Data Transport Options


@CaseyM wrote:

About the race condition, I don't quite see where it comes into play. If you're reading from the DVR in the payload method of your incoming messages, you'll always be acting on the most recent data. On the other hand, using the message approach we'd end up updating the same data internally in the view/logging actors and then I can see a race condition with regards to whether or not the incoming messages are acting upon the very latest data.


Anytime you have information travelling by two different routes (AF message and DVR poll, in this case), you have the potential for a race.  True, if you always want the latest value at the time of message handling then you are OK, but if you ever need value as of message sending then you have a race. 

 

For example, imagine a message that says "tag current value with this note", where "current value" is at time of sending.  A delay in the message can cause the wrong value to be tagged.  You have the events "Value=X", "Tag current value as "this is X", "Value=Y", and there is a possible race between the last two.  No race if there three events all travel as messages.

 

Anyway, my real point is not that you can't avoid race conditions, it is that you now have to make the mental effort to consider them (and possibly the effort to debug them).  Personally, I spend almost zero time worrying about race conditions.  "Obviously no race conditions" is a lot lower effort than "No obvious race conditions".

0 Kudos
Message 11 of 19
(1,073 Views)

@cbutcher wrote:

As a modification to option 1, you could have the subscribe method start a time-delayed send message to self (Aggregator Actor) with the subscriber's enqueuer stored in the message data.

 


If you are going that route, consider having the receiving actors start up a "time-delayed send message" that polls the Data Producing actor.  Then the Receivers have full control, and you can make the Data Producing actor very simple.

0 Kudos
Message 12 of 19
(1,068 Views)

@cbutcher wrote:

As a modification to option 1, you could have the subscribe method start a time-delayed send message to self (Aggregator Actor) with the subscriber's enqueuer stored in the message data.


I think we'd want to avoid this approach for 2 main reasons:

  1. It shares actor enqueuers. We don't want other devs to be tempted to take that enqueuer, store it and use it for who knows what.
  2. I don't like time-delayed messages when the number of messages is >1. Nominally, all the messages received would execute quickly, but you can't guarantee that (sometime both for technical AND interpersonal reasons) so if the payload method were slower to execute than the period of your time delayed message, the message queue grows and timing becomes especially non-deterministic. This is probably a topic unto itself, but we like to put functionality in place that schedules the next message, but only ever the very next message until some confirmation is received that the message is acted upon.
CLA CLED AF Guild
0 Kudos
Message 13 of 19
(1,053 Views)

@drjdpowell wrote:

@CaseyM wrote:

About the race condition, I don't quite see where it comes into play. If you're reading from the DVR in the payload method of your incoming messages, you'll always be acting on the most recent data. On the other hand, using the message approach we'd end up updating the same data internally in the view/logging actors and then I can see a race condition with regards to whether or not the incoming messages are acting upon the very latest data.


Anytime you have information travelling by two different routes (AF message and DVR poll, in this case), you have the potential for a race.  True, if you always want the latest value at the time of message handling then you are OK, but if you ever need value as of message sending then you have a race. 


OK, I see what you were saying. In this case, however, we're only ever interested in the latest value.

CLA CLED AF Guild
0 Kudos
Message 14 of 19
(1,052 Views)

@CaseyM wrote: I don't like time-delayed messages when the number of messages is >1. Nominally, all the messages received would execute quickly, but you can't guarantee that (sometime both for technical AND interpersonal reasons) so if the payload method were slower to execute than the period of your time delayed message, the message queue grows and timing becomes especially non-deterministic. This is probably a topic unto itself, but we like to put functionality in place that schedules the next message, but only ever the very next message until some confirmation is received that the message is acted upon.

I actually ran into this very issue. Just have the message self-schedule for [period] ms after it fires. Store the TDSM notifier in your actor's private data. When you want to stop the messaging, you can stop it the same way you would with a "repeat infinitely" TDSM.

 

In my application, I needed to update a UI both on a set schedule (i.e., poll some settings and update the display) at, IIRC, 2 Hz. I also wanted to do an update immediately when the user performed an action that would update the display. Initially, I had a TDSM running at 500 ms, and certain user events would update it as well. It started to bog things down a bit, so instead of the user action triggering an update right now, it just sent "Send next TDSM" right now instead. The TDSM message would be waiting for its timer to expire, but I need the update right now and don't need another one until 500 ms after the previous update. So just send the "do it now" message on the notifier.

 

You would obviously benefit from wrapping this functionality up in a couple VI's. You could even make it a reuse class if you wanted, that way you wouldn't need to manually handle the notifiers (since you get a new one each time you fire TDSM in one-shot mode).

0 Kudos
Message 15 of 19
(1,047 Views)

@CaseyM wrote:


OK, I see what you were saying. In this case, however, we're only ever interested in the latest value.


In another post you listed two things you don't like to do as other devs might use them incorrectly (shared enqueuers and not handling messages fast).  So why are you OK with this internal assumption, which other devs aren't easily even aware of, so cannot not use incorrectly?

0 Kudos
Message 16 of 19
(1,026 Views)

@drjdpowell wrote:

So why are you OK with this internal assumption, which other devs aren't easily even aware of, so cannot not use incorrectly?



Because in this case it's not actually an internal assumption, but something the client stated.

 

If we thought it likely the requirements were to change (in this particular case, we don't), we'd probably lean toward option 1. 


 

CLA CLED AF Guild
0 Kudos
Message 17 of 19
(1,018 Views)

 


@BertMcMahan wrote: 

Just have the message self-schedule for [period] ms after it fires. Store the TDSM notifier in your actor's private data. When you want to stop the messaging, you can stop it the same way you would with a "repeat infinitely" TDSM.

 

That's essentially what we usually do too with some of those custom wrapper functions you alluded to.

CLA CLED AF Guild
0 Kudos
Message 18 of 19
(1,015 Views)

@CaseyM wrote:

@drjdpowell wrote:

So why are you OK with this internal assumption, which other devs aren't easily even aware of, so cannot not use incorrectly?



Because in this case it's not actually an internal assumption, but something the client stated.

 

If we thought it likely the requirements were to change (in this particular case, we don't), we'd probably lean toward option 1. 


 


Client requirements being reliable and never changing or increasing is something well outside my experience so I can't comment.

0 Kudos
Message 19 of 19
(1,009 Views)