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.

+1

Please remove synchronized all together. It's an abomination which should have never been in D in the first place.
It encourages sloppiness and lobotomizes programmers!
The greatest good you can do to all the D code out there that makes use of synchronized is to kill synchronized.
Then they'll have to think and hopefully learn how to properly synchronize sections of code instead of locking everything everywhere all the time.

On 2015-10-13 14:56, Dicebot wrote:

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

Like DWT :)

-- 
/Jacob Carlborg

On 10/14/15 03:10, Kapps via Digitalmars-d 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. :)
> 
> Though really, that could just be:
> with(mutex.lock()) { }

Yes, but be careful - this is a relatively recent language change (AFAIR it went in during the 'we-don't-need-no-changelog' phase, so this was only documented in a bugzilla entry) _and_ it used to be broken until /very/ recently - the object was destroyed before entering the block. IOW it was executed like:

    auto __tmp = mutex.lock();
    __tmp.__dtor();
    {
       ...
    }

which could result in nasty bugs, because you might not have immediately noticed that you're operating on an already unlocked object.

artur

On 13-Oct-2015 21:28, Marco Leise wrote:
> Am Tue, 13 Oct 2015 12:52:55 +0000
[snip]
> 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. :)

Now how hard would it be to support any object (mutex kind) with lock/unlock?

Or do we even need it with scope(exit)?


-- 
Dmitry Olshansky

On 10/13/15 10:05 PM, 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.

For a while we were of the opinion that we should let "synchronized" and "shared" be and move on with alternative features. Now we believe an incomplete language definition is damaging the language as a whole so we better make them fully defined and useful within their charter.

Lock-based synchronization has plenty of good uses and the scope locking defined by "synchronized" covers a large useful subset of it. We need to make it usable safely and without contortions, and this particular PR is a step along that way.

It's not a huge priority but since Andrej has only done the work, the main concern left is breakage of existing code, albeit much of that is incorrect or unnecessarily unsafe.


Andrei

On 10/14/15 6:33 AM, flamencofantasy wrote:
> 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.
>
> +1
>
> Please remove synchronized all together. It's an abomination which
> should have never been in D in the first place.
> It encourages sloppiness and lobotomizes programmers!
> The greatest good you can do to all the D code out there that makes use
> of synchronized is to kill synchronized.
> Then they'll have to think and hopefully learn how to properly
> synchronize sections of code instead of locking everything everywhere
> all the time.

Scoped locking as embodied by "synchronized" has many meaningful uses. Facebook uses https://github.com/facebook/folly/blob/master/folly/docs/Synchronized.md often and with great results. C++1x has made it a language rule that the entire STL implements mutable and const methods as expected by folly::Synchronized. -- Andrei

On Thursday, 15 October 2015 at 10:11:06 UTC, Andrei Alexandrescu wrote:
>
> Now we believe an incomplete language definition is damaging the language as a whole so we better make them fully defined and useful within their charter.

+1!

---
Paolo

On Thursday, 15 October 2015 at 10:11:06 UTC, Andrei Alexandrescu wrote:
> On 10/13/15 10:05 PM, 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.
>
> For a while we were of the opinion that we should let "synchronized" and "shared" be and move on with alternative features. Now we believe an incomplete language definition is damaging the language as a whole so we better make them fully defined and useful within their charter.
>
> Lock-based synchronization has plenty of good uses and the scope locking defined by "synchronized" covers a large useful subset of it. We need to make it usable safely and without contortions, and this particular PR is a step along that way.
>
> It's not a huge priority but since Andrej has only done the work, the main concern left is breakage of existing code, albeit much of that is incorrect or unnecessarily unsafe.

Unless we're going to decide to get rid of synchronized in favor of just using mutexes and guards/autolocks like you would in C++, I think that it's pretty clear that this change is an improvement. And it's what TDPL has said for something like 5 years now. So, in theory, it's publicly been the plan for some time.

- Jonathan M Davis

On Thursday, 15 October 2015 at 10:11:06 UTC, Andrei Alexandrescu wrote:
>> Yes, and I am saying that it doesn't justify presence of `synchronized`
>> keyword in the language at all, being historical legacy misfeature.
>
> For a while we were of the opinion that we should let "synchronized" and "shared" be and move on with alternative features. Now we believe an incomplete language definition is damaging the language as a whole so we better make them fully defined and useful within their charter.
>
> Lock-based synchronization has plenty of good uses and the scope locking defined by "synchronized" covers a large useful subset of it. We need to make it usable safely and without contortions, and this particular PR is a step along that way.
>
> It's not a huge priority but since Andrej has only done the work, the main concern left is breakage of existing code, albeit much of that is incorrect or unnecessarily unsafe.

You are absolutely correct that incomplete definition is damaging. I can also agree with "plenty of uses" but hardly with "plenty of good uses" though. There are many situations of course where efficient concurrency is not critical and one can go away with straightforward mutex approach. But providing such semantics as language builtin implies it is encouraged and "official" approach and that is rather bad :(

To be honest I'd prefer it to go in "not really deprecated but pretend it doesn't exist" trash bin like scope storage class is.

> the main concern left is breakage of existing code, albeit much of that is incorrect or unnecessarily unsafe.

This is a bit more delicate issue. This code is only incorrect and/or unsafe if used in multi-threaded environment and those fields are actually accessed. There isn't anything broken with such code per se. I agree it should be fixed (with a proper slow deprecation phase) but I am not happy about it.

On 10/14/15 9:24 AM, Jacob Carlborg wrote:
> On 2015-10-13 14:56, Dicebot wrote:
>
>> 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.
>
> Like DWT :)

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.


Andrei