What classification should shared objects in qeued thread pools have?
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
More information about the Digitalmars-d-learn