On Tuesday, 13 October 2015 at 08:55:26 UTC, Benjamin Thaut wrote:
I have to agree here. I think synchronized classes are of very little use, especially because they don't "cast away" shared in a useful way. It still has to be done manually. I think we should remove them. Synchronized methods should also be removed in my eyes. Making each and every object bigger by one pointer just for the sake of a few synchronized methods doesn't seem to be a good trade off to me. The entire synchronized methods give the user the feeling that he simply slaps synchronized on his class / method and then its thread safe and he doesn't have to care about threads anymore. In the real world this is far from true however. So synchronized methods and classes just give a false sense of thread safety and should rather be removed.
I'm fine with having synchronized classes, and I'm fine with having synchronized classes removed from the language entirely.
I think that synchronized functions provide almost no value over simply using mutexes, and they give the false impression that slapping synchronized on it solves the concurrency problem, whereas it's often far more complicated than that. In most cases, it's better to have mutexes be for a specific variable or group of variables, in which case, having a single mutex for the object just risks folks reusing that mutex when they should be creating multiple mutexes. Having a single mutex for a class is usually overly broad - regardless of whether all of the functions in a class are synchronized or only select ones are. And when you _do_ use a single mutex for an entire class, I've found that it's often the case that the mutex shouldn't be part of the class, because you need to lock it with some other piece of data at the same time (e.g. lock a linked list variable and another, related, variable via a lock external to them rather than having the linked list manage its own lock and then need another lock around both of those variables). synchronized on functions/classes is just not a good replacement for explicit mutexes, and it encourages bad practices IMHO.
The primary advantage that I see to synchronized classes is that they can safely, implicitly strip off the outer layer of shared - and that's the only way that we've come up with thus far that we can safely, implicitly strip off shared at all. However, because it's only the outer layer, I'm not sure that it's worth it. And creating whole classes just to encapsulate shared seems like overkill to me, especially if you end up having to cast away shared inside the class anyway. But even then, I would think that a synchronized class makes more sense as a small wrapper around a group of variables that need to be protected by a single mutex than it does to slap synchronized on a class like LinkedList, and I expect that there are going to be plenty of programmers looking to just slap synchronized on a class and have it magically fix their shared problems for them (and then getting annoyed when they still have shared problems inside of the class, because only the outer layer of shared was stripped off).
So, if we have synchronized on classes or functions, I think that we should have synchronized classes, not individually synchronized functions. But I'm not convinced that having either synchronized classes or functions is actually a good idea. So, if we were to decide to deprecate the synchronized attribute altogether, it wouldn't hurt my feelings any. It's a misfeature from Java IMHO. But at least synchronized classes are a valiant attempt to get some value out of it.
- Jonathan M Davis
