pthread_mutex_lock() question

pthread_mutex_lock() question

Post by son.. » Mon, 04 Sep 2000 04:46:04



The question is when there are more than one threads waiting on a
pthread_mutex_lock() and if the owner of the mutex unlocks it which
thread will get to lock the mutex, assuming that all threads are of
equal priority.
The Reason for the question is the following passage from "pthreads
programming O'Reilly & associates "...
----------------------------------------
Appendix C :Pthreads quick reference Page 258
"pthread_mutex_unlock()
 Unlocks a mutex. The scheduling priority determines which blocked
thread is resumed. The resumed thread may not succeed in it s next
attempt to lock the mutex, depending upon whether another thread has
locked the mutex in the interval between the thread's being resumed and
it s issuing the pthread_mutex_lock() call."

-----------

Does this mean that thread A was resumed but another thread ( say B )
got the mutex. I agree I m not very clear about the word "resume". Is
this to mean that the woken up thread will enter some rigorous polling
till it can get the mutex. It sounds like some kind of signalling
between the unlocker and the waiters - like the case of
pthread_cond_signal(). If there was some kind of signalling, can that
be sent to more than one waiting threads. If it can be sent to only one
thread, how can the above condition arise at all, since only one thread
will be woken up which will succeed in locking the mutex. Or is the
signal broadcasted.

Any clarification will be greatly appreciated.

Thanks
Sony

Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

pthread_mutex_lock() question

Post by son.. » Thu, 07 Sep 2000 13:07:13




> The question is when there are more than one threads waiting on a
> pthread_mutex_lock() and if the owner of the mutex unlocks it which
> thread will get to lock the mutex, assuming that all threads are of
> equal priority.
> The Reason for the question is the following passage from "pthreads
> programming O'Reilly & associates "...
> ----------------------------------------
> Appendix C :Pthreads quick reference Page 258
> "pthread_mutex_unlock()
>  Unlocks a mutex. The scheduling priority determines which blocked
> thread is resumed. The resumed thread may not succeed in it s next
> attempt to lock the mutex, depending upon whether another thread has
> locked the mutex in the interval between the thread's being resumed
and
> it s issuing the pthread_mutex_lock() call."

OK I did not get any response. Meanwhile I think I understood what this
means. Please correct me if there is something I missed.

Say there were 2 threads waiting on a mutex and the third thread that
was holding the mutex unlocks it. Not the scheduler schedules one of
the waiting threads to RUNNABLE. But before it gets to run and lock the
mutex, a 4th thread that was not in the picture so far comes and locks
the mutex. Now the woken up guy doesn t get to lock it. So it gets
suspended again in it s attempt to lock trhe mutex.

- Show quoted text -

Quote:

> -----------

> Does this mean that thread A was resumed but another thread ( say B )
> got the mutex. I agree I m not very clear about the word "resume". Is
> this to mean that the woken up thread will enter some rigorous polling
> till it can get the mutex. It sounds like some kind of signalling
> between the unlocker and the waiters - like the case of
> pthread_cond_signal(). If there was some kind of signalling, can that
> be sent to more than one waiting threads. If it can be sent to only
one
> thread, how can the above condition arise at all, since only one
thread
> will be woken up which will succeed in locking the mutex. Or is the
> signal broadcasted.

> Any clarification will be greatly appreciated.

> Thanks
> Sony

> Sent via Deja.com http://www.deja.com/
> Before you buy.

Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

pthread_mutex_lock() question

Post by Stefan Skoglun » Sun, 17 Sep 2000 04:00:00



> was holding the mutex unlocks it. Not the scheduler schedules one of
> the waiting threads to RUNNABLE. But before it gets to run and lock the
> mutex, a 4th thread that was not in the picture so far comes and locks
> the mutex. Now the woken up guy doesn t get to lock it. So it gets
> suspended again in it s attempt to lock trhe mutex.

Which will result in starvation at some time !
 
 
 

pthread_mutex_lock() question

Post by matth.. » Sun, 17 Sep 2000 04:00:00


If the owner of a mutex releases the mutex then it is absolutely based
on the scheduler which thread gets the mutex.  If even all your
requesting threads have the same priority (BTW if there are not
SYSTEM_SCOPE threads, then anyway only your process will be visible and
scheduled by the kernel), the scheduler kicks and decides who gets the
CPU next.  That could be based on a policy like round-robin.  If that
lucky thread then wastes too much time before acquiring the mutex (e.g.
does a blocking system call) then it might get descheduled and another
process (or thread) gets the CPU.

Matthias



> The question is when there are more than one threads waiting on a
> pthread_mutex_lock() and if the owner of the mutex unlocks it which
> thread will get to lock the mutex, assuming that all threads are of
> equal priority.
> The Reason for the question is the following passage from "pthreads
> programming O'Reilly & associates "...
> ----------------------------------------
> Appendix C :Pthreads quick reference Page 258
> "pthread_mutex_unlock()
>  Unlocks a mutex. The scheduling priority determines which blocked
> thread is resumed. The resumed thread may not succeed in it s next
> attempt to lock the mutex, depending upon whether another thread has
> locked the mutex in the interval between the thread's being resumed
and
> it s issuing the pthread_mutex_lock() call."

> -----------

> Does this mean that thread A was resumed but another thread ( say B )
> got the mutex. I agree I m not very clear about the word "resume". Is
> this to mean that the woken up thread will enter some rigorous polling
> till it can get the mutex. It sounds like some kind of signalling
> between the unlocker and the waiters - like the case of
> pthread_cond_signal(). If there was some kind of signalling, can that
> be sent to more than one waiting threads. If it can be sent to only
one
> thread, how can the above condition arise at all, since only one
thread
> will be woken up which will succeed in locking the mutex. Or is the
> signal broadcasted.

> Any clarification will be greatly appreciated.

> Thanks
> Sony

> Sent via Deja.com http://www.deja.com/
> Before you buy.

Sent via Deja.com http://www.deja.com/
Before you buy.
 
 
 

pthread_mutex_lock() question

Post by Casper H.S. Dik - Network Security Engine » Mon, 18 Sep 2000 04:00:00


[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


>If the owner of a mutex releases the mutex then it is absolutely based
>on the scheduler which thread gets the mutex.  If even all your
>requesting threads have the same priority (BTW if there are not
>SYSTEM_SCOPE threads, then anyway only your process will be visible and
>scheduled by the kernel), the scheduler kicks and decides who gets the
>CPU next.  That could be based on a policy like round-robin.  If that
>lucky thread then wastes too much time before acquiring the mutex (e.g.
>does a blocking system call) then it might get descheduled and another
>process (or thread) gets the CPU.

Blocked threads may also get pagefaults which may cause another
thread to run instead.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

1. SIGSEGV in pthread_mutex_lock in RedHat 7.2 gcc 2.95.3

Complete error message and backtrace is below

I'm porting a working program from Linux 8.0 and have a case where
propagating an exception that is covered by a try {} catch{}
a couple of levels up the stack leads to the mentioned SIGSEGV.
This is on RedHat Linux 7.2 on IBM zSeries.

I also have RedHat Linux 7.2 on Intel with gcc 2.96 and this
works correctly.

Any ideas? Might this be the compiler?

Jim
____________________________________________________________________
Program received signal SIGSEGV, Segmentation fault.
0x403eb2d6 in __pthread_mutex_lock (mutex=0x410) at mutex.c:99
99      mutex.c: No such file or directory.
         in mutex.c
Current language:  auto; currently c
(gdb) backtrace
#0  0x403eb2d6 in __pthread_mutex_lock (mutex=0x410) at mutex.c:99
#1  0x402da138 in __libc_free (mem=0x410) at malloc.c:3152
#2  0x00410d46 in __builtin_vec_delete (ptr=0x410) at
../../gcc/cp/new2.cc:62
#3  0x00416a36 in SmException::~SmException (this=0x7ffff988,
__in_chrg=2) at src/cpp/SmException_c.h:65
#4  0x0040e19e in main (argc=1, argv=0x7ffffad4) at src/sample/sample.cpp:21

2. More than 105 keys in X

3. why is pthread_mutex_lock a wrapper?

4. ripping problems

5. pthread_mutex_lock() problem

6. Apache and NSCA. Whats the diff.

7. thread waiting on pthread_mutex_lock() forever (for mutex of type PTHREAD_MUTEX_ERRORCHECK)

8. xdaliclock on Linux

9. pthread_mutex_lock-dual processor-Address out of bounds

10. pthread_mutex_lock() bug ??

11. pthread_mutex_lock fails

12. crashes from pthread_mutex_lock ()

13. pthread_mutex_lock() causes vfork call?!