On Tuesday, 13 October 2015 at 08:55:26 UTC, Benjamin Thaut wrote:
On Tuesday, 13 October 2015 at 07:17:20 UTC, Jonathan M Davis
wrote:
Ultimately, I think that we're better off with TDPL's
definition of synchronized classes than the synchronized
functions that we have now, so I do think that the change
should be made. However, I also think that synchronized
classes as TDPL describes are limited enough to be of
questionable usefulness. Stripping off the outer layer of
shared is unlikely to be sufficient in all but basic cases
(and synchronized classes can't do any better than that, I
don't think), meaning that you're likely going to have to cast
away shared to do much with shared anyway, in which case,
having a synchronized class loses at least some of its value.
It can still encapsulate shared (which is good), but it
doesn't necessarily make it much easier or safer to use.
- Jonathan M Davis
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 agree that synchronized classes / functions that not that
useful.
But synchronized statements, to me, make the intention of locking
explicit.
Maybe the internal monitor could be removed (with synchronized
classes / functions as well), and allow synchronized() {} to be
called on Lock objects, that essentially locks them at the
beginning and unlocks them at the end.
