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