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 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: pragma Thread_Local_Storage on record? Date: Tue, 1 Mar 2016 18:03:08 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <87k2lmmf5w.fsf@mid.deneb.enyo.de> <0e3fb431-ee4b-46ca-b1a5-a78e3245d7f3@googlegroups.com> NNTP-Posting-Host: J5ID10WduBSWFrEOC0Za1A.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:29638 Date: 2016-03-01T18:03:08+01:00 List-Id: On 2016-03-01 17:31, hanslad@gmail.com wrote: >> I don't see how his could be useful for a messages queue which is >> normally shared between several tasks rather than owned by any. The >> latter looks like a low-level implementation-motivated design. > > To explain a bit more: This is just an experiment on implement a small > framework where a set of tasks(one per core) handles a sent of workers > that are messaged by other workers (actor style... I think). The reason > for using Thread_Local_Storage is for performance)I read that somewhere > that it could be a performance gain using that). The idea is that other > workers(handled by other tasks) are sending messages to workers, the > workers are at the same time added to the queue of workers, ready for > action. I dont know if this makes any sense... :-). If this idea has > obvious flaws, please feel free to comment. One problem is that you will have to manage worker tasks. Then you will have to advertise the worker's messages buffer anyway to make it visible outside. That would make allocation of the buffer in the local task storage useless. If the buffer is known outside it could live outside as well. Moreover that would be safer because it will guarantee that the buffer reference never gets dangled, e.g. when its owner task dies prematurely. Regarding worker management, a preferable design is to decouple producers and consumers (of jobs in this case). That is the producer advertises its jobs on some blackboard and consumers (workers) take jobs from the blackboard when they are free. All know the blackboard and nobody knows anybody else. >> A typical solution is Ada.Task_Attributes instantiated with an access >> type to the object. The object is allocated on demand (access >> dereference by the owner task). > > I have considered this, but wanted to try the Thread_Local_Storage > pragma for performance reasons. Whatever performance difference might exist it is negligible compared to the time when a worker is busy. So a queue look up time is of no concern, otherwise, the whole design is bogus, e.g. flooding workers with near to zero time jobs. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de