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 :-/
