Re: How to transfer Class-Wide object to a Task ?

[William FRANCK <william.franck@free.fr>]

Thank you Optikas for your feedback and advice :-)

Sure, the usual design of a multithreaded  'producer' and 'consumer' 
takes advantage of a FIFO round.
I will considering and testing this as Dmitry outlined it for me.

In fact I may considering my design as a FIFO of one (1) (lol) ?

For now I'm implementing the 'Ada.Containers.Indefinite_Holders' in a 
little PoC.
I'l will share this to the group.

As I mentionned, I do use the Stream attributes 'Input and 'Output, and 
is OK in one single program. The challenge for me is to make it work 
(and pass the objects) in a multi-tasking design.

Huh ?!? There is still something to learn about class-wide and 
indefinite type usage :-)


By the way, I really appreciate the support of this group !
Kind regards,
William



On 2019-10-15 14:31:30 +0000, Optikos said:

> On Tuesday, October 15, 2019 at 2:21:51 AM UTC-5, Dmitry A. Kazakov wrote:
>> On 2019-10-14 22:58, William FRANCK wrote:
>> 
>>> Here is the multitasking part (simplified) (working, no issue)
>>> for reading the datafile, and writing it back (after some data-process)
>>> 
>>> My first intention was : while Writing.Bloc is busy writing on the> > 
>>> output file, Reading.Bloc can take 1 record in advance
>> 
>> That is what OS asynchronous I/O does already. But that is aside.
>> 
>>> Now I have to insert the class-wide object passing in the Bloc.
>> 
>> Stream attributes 'Input and 'Output would do.
>> 
>>> As You mentionned, should I use a protected type (FIFO)  instead of 2 
>>> //> > tasks ?
>> 
>> A protected object to synchronize two tasks:
>> 
>> Producer -> FIFO -> Consumer
>> Block put <- PO -> Block get
>> when full          when empty
>> 
>> FIFO does not need interlocking in this scenario. Protected object is> 
>> only to prevent busy waiting at the ends.
>> 
>> Since you are working with streams you can use a storage stream 
>> instead> of raw FIFO:
>> 
>> Producer -> Storage stream -> Consumer
>> Block write when full    Block read when empty
>> 
>> I still do not understand why you serialize and deserialize insted of> 
>> copying bytes as they are.
> 
> Because OPer is apparently migrating code that was in 2 (UNIXesque) 
> processes to instead be 2 threads in the same process.
> 
> William Franck, you really should rework your design to do as Dmitry 
> advises:  FIFO message queues between 2 otherwise asynchronous threads 
> that work on their own slice of the problem (and have their own slice 
> of the problem's data structures).  Under that revised design, only the 
> FIFO's internals need to worry about thread safety, because before 
> posting and after retrieving from the queue the 2 threads run full tilt 
> in their independent territory without interacting with each other.  
> (This of course assumes that there exists some sort of 
> slicing/partitioning of your problem-space, but there usually is if you 
> look intensely enough for well-defined demarcations.)