Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #11091 > unrolled thread

pthread mutex used like a semaphore. Why does it work?

Back to article view | Back to comp.os.linux.misc

Contents

  pthread mutex used like a semaphore.  Why does it work? "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2014-05-18 18:51 +0000
    Re: pthread mutex used like a semaphore.  Why does it work? "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2014-05-18 19:26 +0000
    Re: pthread mutex used like a semaphore.  Why does it work? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2014-05-19 08:32 +0200
      Re: pthread mutex used like a semaphore.  Why does it work? "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2014-05-19 08:16 +0000
    Re: pthread mutex used like a semaphore.  Why does it work? Richard Kettlewell <rjk@greenend.org.uk> - 2014-05-19 09:12 +0100
      Re: pthread mutex used like a semaphore.  Why does it work? "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2014-05-19 08:27 +0000
    Re: pthread mutex used like a semaphore.  Why does it work? Mark <i@dontgetlotsofspamanymore.invalid> - 2014-05-19 10:50 +0100
    Re: pthread mutex used like a semaphore.  Why does it work? Chick Tower <c.tower@deadspam.com> - 2014-05-19 19:16 +0000
      Re: pthread mutex used like a semaphore.  Why does it work? "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2014-05-20 10:24 +0000
        Re: pthread mutex used like a semaphore.  Why does it work? David Brown <david.brown@hesbynett.no> - 2014-05-20 21:27 +0200
        Re: pthread mutex used like a semaphore.  Why does it work? Chick Tower <c.tower@deadspam.com> - 2014-05-21 02:22 +0000
      Re: pthread mutex used like a semaphore.  Why does it work? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-05-20 22:33 -0400
    Re: pthread mutex used like a semaphore.  Why does it work? James Moe <jimoeDESPAM@sohnen-moe.com> - 2014-05-20 11:13 -0700
      Re: pthread mutex used like a semaphore.  Why does it work? "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2014-05-20 19:39 +0000
        Re: pthread mutex used like a semaphore.  Why does it work? Mark <i@dontgetlotsofspamanymore.invalid> - 2014-05-22 08:59 +0100

#11091 — pthread mutex used like a semaphore. Why does it work?

Hi,

I'm looking at a piece of code where one thread locks a mutex at regular 
intervals and a different thread frees that lock.  I thought it was an 
error for a different thread to free a mutex, but it seems to be working 
and there's no error code.

I see the following at http://pubs.opengroup.org/onlinepubs/9699919799/
functions/pthread_mutex_lock.html:

The pthread_mutex_unlock() function shall fail if:

  [EPERM]
    The mutex type is PTHREAD_MUTEX_ERRORCHECK or PTHREAD_MUTEX_RECURSIVE, 
or the mutex is a robust mutex, and the current thread does not own the 
mutex. 


How does a PTHREAD_MUTEX_DEFAULT mutex react if a non-owning thread 
unlocks it?

TIA

[toc] | [next] | [standalone]

#11092

On Sun, 18 May 2014 18:51:22 +0000, Charles T. Smith wrote:

> Hi,
> 
> I'm looking at a piece of code where one thread locks a mutex at regular
> intervals and a different thread frees that lock.  I thought it was an
> error for a different thread to free a mutex, but it seems to be working
> and there's no error code.
> 
> I see the following at http://pubs.opengroup.org/onlinepubs/9699919799/
> functions/pthread_mutex_lock.html:
> 
> The pthread_mutex_unlock() function shall fail if:
> 
>   [EPERM]
>     The mutex type is PTHREAD_MUTEX_ERRORCHECK or
>     PTHREAD_MUTEX_RECURSIVE,
> or the mutex is a robust mutex, and the current thread does not own the
> mutex.
> 
> 
> How does a PTHREAD_MUTEX_DEFAULT mutex react if a non-owning thread
> unlocks it?
> 
> TIA


To elaborate ... is it possible that an undocumented "feature" of the 
linux implementation is that - when a non-owner releases a mutex and 
error checking is not active - the mutex will be released, and this 
effectively implements a simple semaphore?

[toc] | [prev] | [next] | [standalone]

#11094

On 05/18/2014 08:51 PM, Charles T. Smith wrote:
> I'm looking at a piece of code where one thread locks a mutex at regular
> intervals and a different thread frees that lock.  I thought it was an
> error for a different thread to free a mutex, but it seems to be working
> and there's no error code.

It probably "works", but it is also probably... not thread-safe.

[toc] | [prev] | [next] | [standalone]

#11096

On Mon, 19 May 2014 08:32:53 +0200, Xavier Roche wrote:

> On 05/18/2014 08:51 PM, Charles T. Smith wrote:
>> I'm looking at a piece of code where one thread locks a mutex at
>> regular intervals and a different thread frees that lock.  I thought it
>> was an error for a different thread to free a mutex, but it seems to be
>> working and there's no error code.
> 
> It probably "works", but it is also probably... not thread-safe.

In what way, not thread-safe?  You mean if there were more than these two 
threads?  I mean, if it works in this, the intended case, then what could 
be unsafe about it...

[toc] | [prev] | [next] | [standalone]

#11095

"Charles T. Smith" <cts.private.yahoo@gmail.com> writes:
> I'm looking at a piece of code where one thread locks a mutex at regular 
> intervals and a different thread frees that lock.  I thought it was an 
> error for a different thread to free a mutex, but it seems to be working 
> and there's no error code.
>
> I see the following at http://pubs.opengroup.org/onlinepubs/9699919799/
> functions/pthread_mutex_lock.html:
>
> The pthread_mutex_unlock() function shall fail if:
>
>   [EPERM]
>     The mutex type is PTHREAD_MUTEX_ERRORCHECK or PTHREAD_MUTEX_RECURSIVE, 
> or the mutex is a robust mutex, and the current thread does not own the 
> mutex. 
>
>
> How does a PTHREAD_MUTEX_DEFAULT mutex react if a non-owning thread 
> unlocks it?

There’s a table at the top of the page which gives the behavior for the
various cases.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#11097

On Mon, 19 May 2014 09:12:08 +0100, Richard Kettlewell wrote:

> "Charles T. Smith" <cts.private.yahoo@gmail.com> writes:
>> I'm looking at a piece of code where one thread locks a mutex at
>> regular intervals and a different thread frees that lock.  I thought it
>> was an error for a different thread to free a mutex, but it seems to be
>> working and there's no error code.
>>
>> I see the following at http://pubs.opengroup.org/onlinepubs/9699919799/
>> functions/pthread_mutex_lock.html:
>>
>> The pthread_mutex_unlock() function shall fail if:
>>
>>   [EPERM]
>>     The mutex type is PTHREAD_MUTEX_ERRORCHECK or
>>     PTHREAD_MUTEX_RECURSIVE,
>> or the mutex is a robust mutex, and the current thread does not own the
>> mutex.
>>
>>
>> How does a PTHREAD_MUTEX_DEFAULT mutex react if a non-owning thread
>> unlocks it?
> 
> There’s a table at the top of the page which gives the behavior for the
> various cases.


Yes, you're right.
	Mutex Type	Robustness	Relock	Unlock When Not Owner
	NORMAL		non-robust	deadlock undefined behavior

Before I file that as a bug report, I just wanted to be sure that nobody 
would say that "everybody knows that a mutex unlocked by another thread 
is obviously a perfectly good semaphore"!

[toc] | [prev] | [next] | [standalone]

#11098

On Sun, 18 May 2014 18:51:22 +0000 (UTC), "Charles T. Smith"
<cts.private.yahoo@gmail.com> wrote:

>Hi,
>
>I'm looking at a piece of code where one thread locks a mutex at regular 
>intervals and a different thread frees that lock.  I thought it was an 
>error for a different thread to free a mutex, but it seems to be working 
>and there's no error code.
>
>I see the following at http://pubs.opengroup.org/onlinepubs/9699919799/
>functions/pthread_mutex_lock.html:
>
>The pthread_mutex_unlock() function shall fail if:
>
>  [EPERM]
>    The mutex type is PTHREAD_MUTEX_ERRORCHECK or PTHREAD_MUTEX_RECURSIVE, 
>or the mutex is a robust mutex, and the current thread does not own the 
>mutex. 
>
>
>How does a PTHREAD_MUTEX_DEFAULT mutex react if a non-owning thread 
>unlocks it?

It should fail with a EPERM error.  This code must be reliant on a bug
in the implementation of the POSIX threads and should be fixed.
-- 
(\__/)  M.
(='.'=) If a man stands in a forest and no woman is around
(")_(") is he still wrong?

[toc] | [prev] | [next] | [standalone]

#11099

On 2014-05-18, Charles T. Smith wrote:
> How does a PTHREAD_MUTEX_DEFAULT mutex react if a non-owning thread 
> unlocks it?

I think you would have a better chance for an answer in a C newsgroup.
-- 
                                 Chick Tower

For e-mail:  colm DOT sent DOT towerboy AT xoxy DOT net

[toc] | [prev] | [next] | [standalone]

#11100

On Mon, 19 May 2014 19:16:13 +0000, Chick Tower wrote:

> On 2014-05-18, Charles T. Smith wrote:
>> How does a PTHREAD_MUTEX_DEFAULT mutex react if a non-owning thread
>> unlocks it?
> 
> I think you would have a better chance for an answer in a C newsgroup.


Could you recommend one?  The only thing that \.c\. comes up with is 
comp.lang.c.moderated and that appears to be dead.  Although I thought 
that Kettlewell's point was definitive.  Maybe somebody else can suggest 
a way I can break my program, though, to prove to my colleagues that the 
current solution is unacceptable. 

[toc] | [prev] | [next] | [standalone]

#11103

On 20/05/14 12:24, Charles T. Smith wrote:
> On Mon, 19 May 2014 19:16:13 +0000, Chick Tower wrote:
>
>> On 2014-05-18, Charles T. Smith wrote:
>>> How does a PTHREAD_MUTEX_DEFAULT mutex react if a non-owning thread
>>> unlocks it?
>>
>> I think you would have a better chance for an answer in a C newsgroup.
>
>
> Could you recommend one?  The only thing that \.c\. comes up with is
> comp.lang.c.moderated and that appears to be dead.  Although I thought
> that Kettlewell's point was definitive.  Maybe somebody else can suggest
> a way I can break my program, though, to prove to my colleagues that the
> current solution is unacceptable.
>

comp.lang.c is very much alive.  But I wouldn't bother asking about this 
there - after all, this is not a C question.  It's a question about 
mutex's in Linux - you need a Linux newsgroup (or other online forum), 
or perhaps a posix/unix one if it is not Linux specific.

[toc] | [prev] | [next] | [standalone]

#11106

On 2014-05-20, Charles T. Smith <cts.private.yahoo@gmail.com> wrote:
> On Mon, 19 May 2014 19:16:13 +0000, Chick Tower wrote:
>> I think you would have a better chance for an answer in a C newsgroup.
>
> Could you recommend one?  The only thing that \.c\. comes up with is 
> comp.lang.c.moderated and that appears to be dead.

No, sorry.  I'm not a C programmer.  I'm surprised you got useful
responses in this newsgroup.
-- 
                                 Chick Tower

For e-mail:  colm DOT sent DOT towerboy AT xoxy DOT net

[toc] | [prev] | [next] | [standalone]

#11107

On Monday 19 May 2014 15:16, in comp.os.linux.misc, "Chick Tower"
<c.tower@deadspam.com> wrote:

> On 2014-05-18, Charles T. Smith wrote:
>> How does a PTHREAD_MUTEX_DEFAULT mutex react if a non-owning thread
>> unlocks it?
> 
> I think you would have a better chance for an answer in a C newsgroup.

A better choice would be one of: comp.unix.programmer, comp.unix.questions,
or comp.unix.internals

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#11102

On 05/18/2014 11:51 AM, Charles T. Smith wrote:
> I'm looking at a piece of code where one thread locks a mutex at regular 
> intervals and a different thread frees that lock.  I thought it was an 
> error for a different thread to free a mutex, but it seems to be working 
> and there's no error code.
>
  The "owner" is the process in which the mutex is created. If the
threads are all in the same process, there is only the one owner.

-- 
James Moe
jmm-list at sohnen-moe dot com

[toc] | [prev] | [next] | [standalone]

#11104

On Tue, 20 May 2014 11:13:37 -0700, James Moe wrote:

> On 05/18/2014 11:51 AM, Charles T. Smith wrote:
>> I'm looking at a piece of code where one thread locks a mutex at
>> regular intervals and a different thread frees that lock.  I thought it
>> was an error for a different thread to free a mutex, but it seems to be
>> working and there's no error code.
>>
>   The "owner" is the process in which the mutex is created. If the
> threads are all in the same process, there is only the one owner.


I sure hope you're mistaken about that.

[toc] | [prev] | [next] | [standalone]

#11115

On Tue, 20 May 2014 19:39:58 +0000 (UTC), "Charles T. Smith"
<cts.private.yahoo@gmail.com> wrote:

>On Tue, 20 May 2014 11:13:37 -0700, James Moe wrote:
>
>> On 05/18/2014 11:51 AM, Charles T. Smith wrote:
>>> I'm looking at a piece of code where one thread locks a mutex at
>>> regular intervals and a different thread frees that lock.  I thought it
>>> was an error for a different thread to free a mutex, but it seems to be
>>> working and there's no error code.
>>>
>>   The "owner" is the process in which the mutex is created. If the
>> threads are all in the same process, there is only the one owner.
>
>
>I sure hope you're mistaken about that.

He is.  See my earlier post.
-- 
(\__/)  M.
(='.'=) If a man stands in a forest and no woman is around
(")_(") is he still wrong?

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web