Re: pragma Thread_Local_Storage on record?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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