A working way to improve the "shared" situation

Sönke Ludwig sludwig at outerproduct.org
Tue Nov 20 23:41:23 PST 2012


Am 21.11.2012 07:11, schrieb deadalnix:
> Le 15/11/2012 08:56, Sönke Ludwig a écrit :
>> Since the "Something needs to happen with shared" thread is currently split up into a low level
>> discussion (atomic operations, memory barriers etc.) and a high level one (classes, mutexes), it
>> probably makes sense to explicitly state that this proposal here applies more to the latter.
> 
> One problem remains : even with isolated like you propose, some memory barriers are required
> (acquire/release semantic is required). So it does seems pretty hard to get away with it only using
> lib.

Right, it only solves the lock-based part of the shared world, where the mutex ensures proper
acquire/release.

As for the rest, after all that discussion I'm still not convinced that letting the compiler insert
something automatically makes sense - it may impair performance, just avoids a small part of the
pool of potential bugs and only really works for small types. Just disallowing all usual operations
on shared values*, making sure that access follows volatile semantics and providing the appropriate
atomic operations/barriers as functions/intrinsics looks like a sufficient solution to me, given how
seldom this is needed and how critical the details are - and that seems about to be the status quo.

But since I only have lock-free stuff in a few places and I'm sure that those can be kept working
with whatever the final system will look like, I'm not so strongly opinionated there. It's different
with lock based stuff, this is currently just an unusable mess and a strict/safe solution that is
later relaxed is probably a better plan than the opposite (e.g. if synchronized classes would
automatically provide access to their non-shared fields from inside of their methods).


* Just noticed that this is another case for Rebindable!T as you usually do not want to disallow
non-atomic access to a shared class reference, but sometimes you need to. A nice little syntax for
the head-X and X distinction would be so nice :-/


More information about the Digitalmars-d mailing list