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

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.

Well, as I understand it, technically, synchronized classes don't even exist in D at the moment - just synchronized functions (much as TDPL talks about D having synchronized classes and not synchronized functions). So, if that change only affects classes marked with synchronized and doesn't do anything to functions marked as synchronized, then the breakage is likely to be pretty small (pretty much just cases where someone didn't want to bother putting synchronized on every method individually). On the other hand, if it basically adds synchronized classes and disallows synchronized functions and actually moves us to what TDPL describes (or close to it), then it's basically going to break all uses of synchronized in classes aside from simply using synchronized blocks inside of a member function. If it's the latter, we definitely need an appropriate transition period.

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

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

While we're talking about this, what about this:

http://www.digitalmars.com/d/archives/digitalmars/D/Module_access_to_private_members_of_synchronized_classes_228775.html

> In the TDPL, on page 419:
> "Not so for synchronized classes, which obey the following rules:
- Access to private members is restricted to methods of the class."

I could rework commits from my experimental branch and submit a PR?

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.

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.

Actually, I once fell foul of this wrong impression of thread safety via 'synchronized'. I found a different solution and dropped synchronized.

On Tuesday, 13 October 2015 at 09:07:54 UTC, Chris wrote:
> 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.
>
> Actually, I once fell foul of this wrong impression of thread safety via 'synchronized'. I found a different solution and dropped synchronized.

I also dropped synchronized and use @nogc mutexes instead. I also think synchronized methods should be removed. It's also difficult to explain: what is a "monitor"? when you write a synchronized { } block, which monitor is taken?

Am Tue, 13 Oct 2015 09:36:22 +0000
schrieb ponce <contact@gam3sfrommars.fr>:

> On Tuesday, 13 October 2015 at 09:07:54 UTC, Chris wrote:
> > On Tuesday, 13 October 2015 at 08:55:26 UTC, Benjamin Thaut wrote:
> >>
> >> […] 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.
> >
> > Actually, I once fell foul of this wrong impression of thread safety via 'synchronized'. I found a different solution and dropped synchronized.
> 
> I also dropped synchronized and use @nogc mutexes instead. I also think synchronized methods should be removed. It's also difficult to explain: what is a "monitor"? when you write a synchronized { } block, which monitor is taken?

Yep, I prefer to think it sets of variables that need mutex protection. And these are not generally the set of member fields in a class. When other mutexes need the same variables they must be a strict superset or subset of the other with the mutex with smaller scope always being locked first.

That's all folks. 100% safety. :)
(The catch is you need to get a fix on the variables.)

-- 
Marco

On Tuesday, 13 October 2015 at 10:57:55 UTC, Marco Leise wrote:
>
> Yep, I prefer to think it sets of variables that need mutex protection. And these are not generally the set of member fields in a class.

Exactly. And that makes things using synchronized prone to longer and more frequent locks.

On Tuesday, 13 October 2015 at 09:36:23 UTC, ponce wrote:
> It's also difficult to explain: what is a "monitor"?

Not difficult? A monitor is facade/object which only allows one method to execute concurrently.

It can work out ok if synchronization/lockfree mechanisms are built into the language so that the compiler can optimize away overhead.

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.