https://issues.dlang.org/show_bug.cgi?id=22555

FeepingCreature <default_357-line@yahoo.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |normal

--- Comment #1 from FeepingCreature <default_357-line@yahoo.de> ---
Seems to happen on Linux and Windows.

--

https://issues.dlang.org/show_bug.cgi?id=22555

--- Comment #2 from FeepingCreature <default_357-line@yahoo.de> ---
I don't see any good way in fact to fix this while Mutex is recursive. I've been playing with approaches all day, but the problem is that the interaction of pthread_cond_wait and mutexes leaves it fairly open whether the mutex is actually locked after pthread_mutex_wait has returned - and there is no way to check!

--

https://issues.dlang.org/show_bug.cgi?id=22555

Stanislav Blinov <stanislav.blinov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stanislav.blinov@gmail.com

--- Comment #3 from Stanislav Blinov <stanislav.blinov@gmail.com> ---
I might be wrong, but isn't what's happening here this?

- task starts, locks a's monitor and blocks in wait
- main thread calls set and blocks trying to lock a's monitor, which is already
locked by task

I.e. you've a deadlock, but not on condition variable :)

--

https://issues.dlang.org/show_bug.cgi?id=22555

--- Comment #4 from Stanislav Blinov <stanislav.blinov@gmail.com> ---
Disregard, I'm blind.

--

https://issues.dlang.org/show_bug.cgi?id=22555

--- Comment #5 from Stanislav Blinov <stanislav.blinov@gmail.com> ---
Actually, no, I'm not blind :)

task {
    synchronized (a) // lock, counter = 1
    {
        a.wait(5)
        {
            // `this` is a
            synchronized (this) // already locked, counter = 2
            {
                // So at this point, you've recursed twice
                // hence main thread blocks in set()
                condition.wait; // counter = 1, not unlocked
                // counter = 2
            }
        }
    }
}

---

synchronized(a) in task should be removed

--

https://issues.dlang.org/show_bug.cgi?id=22555

--- Comment #6 from FeepingCreature <default_357-line@yahoo.de> ---
No, because the way conditions work is that they unlock their associated mutex while they wait as an atomic operation, ie. the condition and the mutex are linked.

You can check this by removing the synchronized in the *task* in main, which should be redundant with the one in wait - but then it works.

The problem is recursive mutexes interacting badly with conditions.

--

https://issues.dlang.org/show_bug.cgi?id=22555

--- Comment #7 from FeepingCreature <default_357-line@yahoo.de> ---
Owait yes your observation is correct. But that's not something that shows up in D's semantics for Mutex; and would be annoying at any rate because D core.sync does not have non-recursive mutexes in the first place. Ie. since synchronized is supposed to allow double locking, it should still work with core.sync.Condition. D's impl leaks a pthread problem in other words.

--

https://issues.dlang.org/show_bug.cgi?id=22555

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3

--

https://issues.dlang.org/show_bug.cgi?id=22555

--- Comment #8 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/dmd/issues/17199

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB

--