On Friday, 16 October 2015 at 06:49:06 UTC, Dicebot wrote:
> On Friday, 16 October 2015 at 06:26:30 UTC, Jacob Carlborg wrote:
>> On 2015-10-15 16:28, Andrei Alexandrescu wrote:
>>
>>> That may be worrisome. Any information on how many are using DWT, and
>>> how badly it would break if we pulled the change?
>>>
>>> If we assess there's too much breakage, we can define a DIP and make the
>>> check opt-in via a flag -dipNN.
>>
>> I would like to add that the impact of a possible breakage depends on what the alternative is. If a function in Phobos or druntime is provided with the same functionality, then the breakage have less of an impact.
>
> As far as I understand topic is about deprecating direct field access of synchronized classes, method calls in synhronized classes and `synchronized () {}` blocks will remain untouched.

That clarifies things. It seems a fine idea. I can't think of an instance where it would be advisable to have public mutable fields in a synchronized class. Immutable or const though, sure.

On Friday, 16 October 2015 at 21:54:11 UTC, Jonathan M Davis wrote:
> [...]

std.concurrency.MessageBox is an example of why you might mix synchronized and non-synchronized data in a class. No methods are synchronized though because it's too blunt an instrument. Synchronization happens internally at the statement level.

On 2015-10-16 23:54, Jonathan M Davis wrote:

> Well, you probably will at some point, even if you don't know. According
> to TDPL, there's not supposed to be any such thing as a class with some
> functions which are synchronized and some not. The entire class is
> synchronized or none of it is, and if the class is synchronized then the
> member variables of the class are not accessible outside of the class.
> But that hasn't been implemented yet. Instead, we have synchronized
> functions like in Java. The PR that this thread is about makes it so
> that the member variables aren't accessible outside of the class, which
> probably won't cause DWT any problems, since public member variables are
> generally a bad idea. However, if this PR (or a future PR) actually
> finishes implementing synchronized classes (I don't know how far this PR
> actually goes), then any classes that DWT has which have any
> synchronized functions would then have to be synchronized classes. So,
> while the current PR may not break DWT, odds are that at some point in
> the future, synchronized classes will be finished, and DWT will probably
> break. It wouldn't surprise me if fixing it were fairly easy -
> particularly if DWT tends to synchronize all of the functions in a class
> when it synchronizes any of them - but at bare minimum, you're probably
> going to have to move the synchronized keyword from the function
> declarations to the class declaration, and it's possible that some of
> the implementation will have to change to cope with the fact that it's
> then not legal to have some functions in a class synchronized while
> others aren't.

Basically all of the usage of the "synchronized" keyword in DWT is actually the synchronized statement. I found a couple of more false positives where "synchronized" was part of a method name. There are cases where not all of the methods contain the synchronized statement.

-- 
/Jacob Carlborg

On Sunday, 18 October 2015 at 15:51:50 UTC, Jacob Carlborg wrote:
> On 2015-10-16 23:54, Jonathan M Davis wrote:
> Basically all of the usage of the "synchronized" keyword in DWT is actually the synchronized statement. I found a couple of more false positives where "synchronized" was part of a method name. There are cases where not all of the methods contain the synchronized statement.

Ah. I misunderstood then. I wouldn't expect there to be any changes which would break synchronized statements unless we got rid of synchronized entirely, which is unlikely.

- Jonathan M Davis

On 16/10/2015 08:02, Jacob Carlborg wrote:
> On 2015-10-16 08:49, Dicebot wrote:
>
>> As far as I understand topic is about deprecating direct field access of
>> synchronized classes, method calls in synhronized classes and
>> `synchronized () {}` blocks will remain untouched.
>
> Is it even possible to do synchronized classes in Java? That is, but
> synchronized on the class declaration as in D.
>

No, it's not possible. `synchronized` in Java can only apply to methods, or the synchronized statement.

And (for a change), rightly so that it's not possible. This synchronized class feature seems to me a clumsy mis-feature. At first glance at least.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On Tuesday, 20 October 2015 at 18:15:05 UTC, Bruno Medeiros wrote:
> On 16/10/2015 08:02, Jacob Carlborg wrote:
>> On 2015-10-16 08:49, Dicebot wrote:
>>
>>> As far as I understand topic is about deprecating direct field access of
>>> synchronized classes, method calls in synhronized classes and
>>> `synchronized () {}` blocks will remain untouched.
>>
>> Is it even possible to do synchronized classes in Java? That is, but
>> synchronized on the class declaration as in D.
>>
>
> No, it's not possible. `synchronized` in Java can only apply to methods, or the synchronized statement.
>
> And (for a change), rightly so that it's not possible. This synchronized class feature seems to me a clumsy mis-feature. At first glance at least.

This change seems like a good idea.

As far as having synchronized classes go. I think they can be useful. If, as some of the respondents have said a synchronized class is wrong, then perhaps their classes are too big and indeed require fine grained locks everywhere. Or, if it is performance you are after, then that is the way you might do it.

If, however, you would like better defense against multi-threaded related breakage against your non time-critical class, a class wide lock, surely, would be of benefit.