Re: Backport condition variables and reentrant locks.

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Backport condition variables and reentrant locks.

Dawid Kurzyniec
Maciej Szefler wrote:

>Dawid,
>
>Great job with the backport, its  a life saver. However, I have recently
>run into a problem. It seems that the condition variables do not work as
>advertised with reentrant locks. I find that if a thread has multiple
>holds on a reentrant lock a conditional variable await() call will only
>release one of those holds.  This is contrary to expectations (at least
>mine and the JavaDoc author's).
>
>  
>
You are right. This is a bug. Conditional variables in the backport were
derived from dl.util.concurrent.CondVar, which was POSIX-style
condition, supposed to work with non-reentrant mutexes. It should be
easy to fix; I will include the fix in the next release (probably 2-3
weeks from now).

Regards,
Dawid

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Re: Backport condition variables and reentrant locks.

Alexander Terekhov-2

You better include an incarnation of pthread_mutex_setlockcount_np() and
let your
clients shoot themselves in the foot.

regards,
alexander.



Sent by:    [hidden email]

To:    Maciej Szefler <[hidden email]>
cc:    [hidden email]
Subject:    [concurrency-interest] Re: Backport condition variables and
       reentrant locks.


Maciej Szefler wrote:

>Dawid,
>
>Great job with the backport, its  a life saver. However, I have recently
>run into a problem. It seems that the condition variables do not work as
>advertised with reentrant locks. I find that if a thread has multiple
>holds on a reentrant lock a conditional variable await() call will only
>release one of those holds.  This is contrary to expectations (at least
>mine and the JavaDoc author's).
>
>
>
You are right. This is a bug. Conditional variables in the backport were
derived from dl.util.concurrent.CondVar, which was POSIX-style
condition, supposed to work with non-reentrant mutexes. It should be
easy to fix; I will include the fix in the next release (probably 2-3
weeks from now).

Regards,
Dawid

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Re: Backport condition variablesand reentrant locks.

Dawid Kurzyniec
Alexander Terekhov wrote:

>You better include an incarnation of pthread_mutex_setlockcount_np() and
>let your
>clients shoot themselves in the foot.
>
>  
>
I am not sure I follow; what I meant was: the JSR 166 conditional
variables work with reentrant variables, so should the backport version.
The current backport implementation of await() simply releases the lock
once, and then reacquires it once, which leads to the erroneous behavior
when the thread has multiple holds. The fix I am going to make is for
await() to release all holds, remembering how many there were, and then
reacquire all of them before returning. That's how Object.wait() behaves
for built-in locks.

Regards,
Dawid

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Re: Backport condition variablesand reentrant locks.

Alexander Terekhov-2

http://lists.boost.org/Archives/boost/2004/07/68013.php

regards,
alexander.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

RE: Re: Backportcondition variablesand reentrant locks.

David Holmes
Alex,

> http://lists.boost.org/Archives/boost/2004/07/68013.php

This is totally irrelevant for j.u.c Conditions with ReentrantLock. It's
semantics are already defined.

David Holmes

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

RE: Re: Backportcondition variablesand reentrant locks.

Alexander Terekhov-2

Wrongly defined. OK, back to lurking.

regards,
alexander.

"David Holmes" <[hidden email]>@cs.oswego.edu on 08/12/2005 12:55:38
AM

Sent by:    [hidden email]


To:    <[hidden email]>
cc:
Subject:    RE: [concurrency-interest] Re:      Backportcondition
       variablesand     reentrant locks.


Alex,

> http://lists.boost.org/Archives/boost/2004/07/68013.php

This is totally irrelevant for j.u.c Conditions with ReentrantLock. It's
semantics are already defined.

David Holmes

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest