On Thursday, 1 October 2020 at 14:12:24 UTC, Ola Fosheim Grøstad
wrote:
Also, atomic operations on members do not ensure the integrity
of the struct. For that you need something more powerful
(complicated static analysis or transactional memory).
I'm very wary of being able to cast away
On Thursday, 1 October 2020 at 00:13:41 UTC, IGotD- wrote:
For example completely lockless algorithms can often be a
combination of atomic operations and also non-atomic operations
on data members.
Also, atomic operations on members do not ensure the integrity of
the struct. For that you
On Thursday, 1 October 2020 at 00:13:41 UTC, IGotD- wrote:
I think that the shared in shared structs should not be
transitive to members of the struct. The compiler should not
Once the aggregate struct data is decl-ed `shared` as a whole, it
needs to be transitive to play safe.
The compiler
On Thursday, 1 October 2020 at 00:00:06 UTC, mw wrote:
I think using `shared` is the D's encouraged way.
If there is a better way do this in D, I'd want to know it too.
I think that the shared in shared structs should not be
transitive to members of the struct. The compiler should not
On Thursday, 1 October 2020 at 00:00:06 UTC, mw wrote:
On Wednesday, 30 September 2020 at 20:13:47 UTC, IGotD- wrote:
[...]
I think declaring the container and item as `shared` is the D's
encouraged way of sharing data among different threads.
[...]
then just cast the `shared` away:
On Wednesday, 30 September 2020 at 20:13:47 UTC, IGotD- wrote:
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
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
