On 10/10/13 7:37 PM, Michel Fortin wrote:
On 2013-10-11 02:08:02 +0000, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> said:
On 10/10/13 7:04 PM, Jonathan M Davis wrote:
On Thursday, October 10, 2013 18:21:52 Andrei Alexandrescu wrote:
You can't EVER expect to obtain all of that magic by plastering
"shared"
on top of your type.
It works just fine with the idiom that I described where you protect
the usage
of the object with a lock, cast it to thread-local to do stuff on it,
and then
release the lock (making sure that no thread-local references remain).
TDPL describes how synchronized automatically peels off the "shared"
off of direct members of the object. Unfortunately that feature is not
yet implemented.
That "direct member" limitation makes the feature pretty much worthless.
It's rare you want to protect a single integer behind a mutex, generally
you protect data structures like arrays or trees, and those always have
indirections.
It's not about a single integer, it's about multiple flat objects. True,
many cases do involve indirections.
You could loosen it up a bit by allowing pure functions to use the
member. But you must then make sure those functions won't escape a
pointer to the protected structure through one of its argument, or the
return value. That won't work with something like std.range.front on an
array.
Anyway, that whole concept of synchronized class is a deadlock honeypot.
It should be scrapped altogether.
People still use it.
Andrei
