On Thursday, October 10, 2013 19:08:02 Andrei Alexandrescu wrote: > 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.
I think that it's generally overkill to create a whole class just to protect one shared object. Simply protecting it when you need to with mutex or synchronized block should be enough, and I don't see the cast as being all that big a deal. What TDPL describes is essentially the same except that the compiler does it automatically, but it forces you to create a class just for that. And as Michel points out, removing shared on a single level is frequently not all enough. I think that synchronized classes have their place, but I also think that they're overkill for most situations. Why should I have to create a class just so that I can make a variable thread-local so that I can operate on it? I can do the same with a cast without the extra overhead and a lot more flexibly, since a cast doesn't have the single-level restriction that a synchronized class does. - Jonathan M Davis
