Mallocator and 'shared'
Kagamin via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Mon Feb 13 06:20:05 PST 2017
On Sunday, 12 February 2017 at 20:08:05 UTC, bitwise wrote:
> Given that both the data and the method are 'shared', a caller
> should know that race conditions are possible and that they
> should aquire a lock before accessing either of them...or so it
> would seem.
Thread unsafe methods shouldn't be marked shared, it doesn't make
sense. If you don't want to provide thread-safe interface, don't
mark methods as shared, so they will not be callable on a shared
instance and thus the user will be unable to use the shared
object instance and hence will know the object is thread unsafe
and needs manual synchronization.
ps Memory barriers are a bad idea because they don't defend from
a race condition, but they look like they do :) use
std.concurrency for a simple and safe concurrency, that's what
it's made for.
More information about the Digitalmars-d-learn
mailing list