Synchronized classes have no public members

[Jonathan M Davis via Digitalmars-d]

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