Re: asynchronous task communication

[Charles Hixson <charleshixsn@earthlink.net>]

On 01/03/2013 04:11 AM, Georg Bauhaus wrote:
> On 03.01.13 02:30, Charles Hixson wrote:
>> I guess a part of the question is "What is the overhead on a protected
>> variable?". If it's small, then I'd prefer to have one attached to
>> every cell, as it eliminates one centralized spot of contention, and
>> means that slightly simpler messages can be passed.
>
> Chances are that a protected object employs a locking mechanism
> of the OS (at least in a "PC run-time"). This is probably not the
> fastest, leanest thing to have. However, I guess you could use
> CAS based access to the letter boxes, in particular if the number
> of messages is fixed.
>
> Pat Rogers has illustrated an example, also referred to in Ada
> Gems #93 and #98,
> http://benchmarksgame.alioth.debian.org/u32q/program.php?test=chameneosredux&lang=gnat&id=2
>
> http://www.adacore.com/adaanswers/gems/gem-93-high-performance-multi-core-programming-part-1/
>
>
Unfortunately, the size is not fixed.  I can say that there is one 
mailbox per cell, but the number of cells is not fixed either.  And 
while I'm planning on limiting the size (capacity) of the mailbox, the 
largest size is expected to be far larger than the mean size.

OTOH, simplifying things is that the mailbox has only one reader, and 
writers, except the reader, can only append.  Also, the reader, "takes 
possession" of the contents of the mailbox, and replaces it with an 
empty mailbox.  At least that's my current design.  I've been 
contemplating a modified design where the mailbox is "attached" to the 
cell, and hold both out-going and in-coming messages.   There would also 
need to be a "letter-carrier" that collected and distributed the 
messages.  This would reduce the sync requirements to a boolean flag set 
and cleared by the mailbox accessors that said whether the mailbox was 
busy.  If it was busy, the accessing task could decide whether to wait a 
bit or to do something else and the try again.  This would require a 
"clear and set" on the flag, but nowhere else.
This modified design appears clearly superior if there are enough tasks 
that one can be assigned to be the letter-carrier, and I guess that if I 
arrange it to be inactive most of the time it might work even on my 
limited system.  (Actually the real design would then make the cell 
logically dependent on the mailbox, as in normal operation the mailbox 
could control the rolling in of the cell from secondary storage. 
Perhaps only occasionally would the entire roster of cells be 
sequentially activated.)

This idea for a design modification is because an investigation of 
sizing constraints shows that the original design it totally impossible 
on my system.  Even this redesigned system may need to be modified so 
that mailboxes spend much of their time on disk, if I can devise a way 
to enable this.  Perhaps some sort of rolling activation.  Virtual 
memory isn't a plausible answer because the program needs to be able to 
save its state quickly and shutdown...and then to pick-up where it left 
off.  (But this is getting far away from the original problem of 
concurrent design, which now looks solved...I've got in hand a design 
for a CAS based stack, which is all that the mailbox needs, though I 
need to modify it a bit to "popall" rather than simply "pop".)