On Tuesday, 13 October 2015 at 12:20:17 UTC, Minas Mina wrote:
>
> I agree that synchronized classes / functions that not that useful.
>
> But synchronized statements, to me, make the intention of locking explicit.

Synchronized statements are fine and serve a good purpose, no need to delete them in my opinion.

>
> 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.

Yes, I would love that.

On Tuesday, 13 October 2015 at 12:51:14 UTC, Benjamin Thaut wrote:
> On Tuesday, 13 October 2015 at 12:20:17 UTC, Minas Mina wrote:
>>
>> I agree that synchronized classes / functions that not that useful.
>>
>> But synchronized statements, to me, make the intention of locking explicit.
>
> Synchronized statements are fine and serve a good purpose, no need to delete them in my opinion.
>
>>
>> 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.
>
> Yes, I would love that.

Isn't dedicated language feature a bit too much for a glorified mutex scope guard?

On Tuesday, 13 October 2015 at 06:58:28 UTC, Andrei Alexandrescu wrote:
> https://github.com/D-Programming-Language/dmd/pull/5188 implements a rule defined in TDPL: synchronized classes shall have no public members.
>
> The motivation behind this limitation is that member accesses in synchronized objects should not occur without some handshake occurring. Public members would make that possible and easy.
>
> Walter and I are on board with this change. However, it is a breaking change so we want to gather a level of community support before we push the button.
>
>
> Thanks,
>
> Andrei

I still have no idea why I would ever use `synchronized` (any automatic thread synchronization is harmful in my opinion) so change itself is irrelevant. But it may break quite some old Java-liked 3d party code for no benefit and that would be annoying.

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

Am Tue, 13 Oct 2015 12:52:55 +0000
schrieb Dicebot <public@dicebot.lv>:

> On Tuesday, 13 October 2015 at 12:51:14 UTC, Benjamin Thaut wrote:
> > On Tuesday, 13 October 2015 at 12:20:17 UTC, Minas Mina wrote:
> >>
> >> I agree that synchronized classes / functions that not that useful.
> >>
> >> But synchronized statements, to me, make the intention of locking explicit.
> >
> > Synchronized statements are fine and serve a good purpose, no need to delete them in my opinion.
> >
> >>
> >> 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.
> >
> > Yes, I would love that.
> 
> Isn't dedicated language feature a bit too much for a glorified mutex scope guard?

Guys, sorry to break into your wishful thinking, but

   synchronized(mutex) {}

already works as you want it to since as long as I can think. Yes, it takes a parameter, yes it calls lock/unlock on the mutex. :)

-- 
Marco

On Tuesday, 13 October 2015 at 18:28:23 UTC, Marco Leise wrote:
> Guys, sorry to break into your wishful thinking, but
>
>    synchronized(mutex) {}
>
> already works as you want it to since as long as I can think. Yes, it takes a parameter, yes it calls lock/unlock on the mutex. :)

Yes, and I am saying that it doesn't justify presence of `synchronized` keyword in the language at all, being historical legacy misfeature.

On Tuesday, 13 October 2015 at 19:05:31 UTC, Dicebot wrote:
> On Tuesday, 13 October 2015 at 18:28:23 UTC, Marco Leise wrote:
>> Guys, sorry to break into your wishful thinking, but
>>
>>    synchronized(mutex) {}
>>
>> already works as you want it to since as long as I can think. Yes, it takes a parameter, yes it calls lock/unlock on the mutex. :)
>
> Yes, and I am saying that it doesn't justify presence of `synchronized` keyword in the language at all, being historical legacy misfeature.

The same can be done trivially with a guard/autolock object, because we have RAII. It can also be done with scope statements, though that's more verbose. I suspect that C# has it primarily because they don't have RAII.

I don't know that it really hurts D to have synchronized statements, but I do agree that they really don't add much in the way of value. And it's not like it's hard to come up with cases where they don't even work, whereas a guard/autolock could (e.g. having to unlock the mutex partway through a block, possibly relocking it later in the block, possibly not).

- Jonathan M Davis

On Tuesday, 13 October 2015 at 18:27:43 UTC, Jonathan M Davis wrote:
> 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

Monitor classes is a high level convenience feature that one has to put work into if it is to be good. It is however much less error prone than mutexes and semaphores.

The point is that you create a robust encapsulated facade and only weaken the facade after static analysis has proven that locks are superfluous. Doing this manually is error prone.

One can also add high level concurrency mechanisms like guarantees for obtaining a set of resources before obtaining the lock, e.g. the caller supplies a predicate like "user Eric and user Lisa is available" and is suspended until the predicate is satisfiable.

But it needs more high level features than D has today.

On Tuesday, 13 October 2015 at 18:28:23 UTC, Marco Leise wrote:
>
> Guys, sorry to break into your wishful thinking, but
>
>    synchronized(mutex) {}
>
> already works as you want it to since as long as I can think. Yes, it takes a parameter, yes it calls lock/unlock on the mutex. :)

Though really, that could just be:
with(mutex.lock()) { }

On Tuesday, 13 October 2015 at 06:58:28 UTC, Andrei Alexandrescu wrote:
> https://github.com/D-Programming-Language/dmd/pull/5188 implements a rule defined in TDPL: synchronized classes shall have no public members.
>
> The motivation behind this limitation is that member accesses in synchronized objects should not occur without some handshake occurring. Public members would make that possible and easy.
>
> Walter and I are on board with this change. However, it is a breaking change so we want to gather a level of community support before we push the button.
>
>
> Thanks,
>
> Andrei

Ignoring the issue of whether synchronized should actually exist, this makes sense to me. Any class that expects to be thread-safe should not allow public access to fields as that's inherently not thread-safe. Code breakage would exist, but if the user really wants to maintain the same logic, they could just use @property in the vast majority of cases.