What classification should shared objects in qeued thread pools have?

IGotD- nise at nise.com
Wed Sep 30 20:13:47 UTC 2020

I have a system that heavily relies on thread pools. Typically 
this is used with items that are put on a queue and then a thread 
pool system process this queue. The thread pool can be configured 
to process the items in whatever parallel fashion it wants but 
usually it is set to one, that means no special protection for 
concurrency is needed as serialization is guaranteed. One item is 
processed at a time.

So think that one item is being processed and then put on some 
kind of dynamic data structure. During this operation allocations 
and deallocations can happen. Because we have a thread pool, 
these memory operations can happen in different threads.

This where the memory model of D starts to become confusing for 
me. By default memory allocations/deallocation are not allowed 
between threads, however setting the object to shared circumvents 
this. This seems to work as there is no more aborts from the D 
memory management. However, this has a weird side effect. Now the 
compiler wants that all my integer member variables operates by 
using atomic primitives. I don't need this, I know that this 
object will be sequentially used.

Is shared the wrong way to go here and is there another way to 
solve this?

More information about the Digitalmars-d-learn mailing list