From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!cleanfeed3-b.proxad.net!nnrp1-1.free.fr!not-for-mail From: William FRANCK Newsgroups: comp.lang.ada Date: Tue, 15 Oct 2019 21:41:32 +0200 Message-ID: <5da620ec$0$21604$426a74cc@news.free.fr> References: <5da4cf81$0$20312$426a74cc@news.free.fr> <5da4e182$0$20321$426a74cc@news.free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: How to transfer Class-Wide object to a Task ? User-Agent: Unison/2.2 Organization: Guest of ProXad - France NNTP-Posting-Date: 15 Oct 2019 21:41:32 CEST NNTP-Posting-Host: 92.184.97.242 X-Trace: 1571168492 news-2.free.fr 21604 92.184.97.242:40217 X-Complaints-To: abuse@proxad.net Xref: reader01.eternal-september.org comp.lang.ada:57293 Date: 2019-10-15T21:41:32+02:00 List-Id: 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.)