calling mutex_lock() twice from one thread

calling mutex_lock() twice from one thread

[Bastian Voigt]

Dear list,

according to the documentation pthread_mutex_lock() assigns the mutex to 
the calling thread, and if a different thread calls it again it will be 
blocked.

In my scenario I want one thread to block itself, to be waked up later 
by a signal handler. This does not work by simply calling mutex_lock() 
twice, it does not block.

What can you recommend to achieve this? To be more concrete, I do the 
following:

The main thread loads some configuration, then starts some worker 
threads. After the worker threads are running I want the main thread to 
sleep until a signal (Ctrl-C) arrives. Will it work better when using 
semaphores?

Thanks for any hints!

Bastian Voigt

Re: calling mutex_lock() twice from one thread

[Nicolas EDEL]

Bastian Voigt wrote:
> Dear list,
> 
> according to the documentation pthread_mutex_lock() assigns the mutex to 
> the calling thread, and if a different thread calls it again it will be 
> blocked.
> 
> In my scenario I want one thread to block itself, to be waked up later 
> by a signal handler. This does not work by simply calling mutex_lock() 
> twice, it does not block.
> 
> What can you recommend to achieve this? To be more concrete, I do the 
> following:
> 
> The main thread loads some configuration, then starts some worker 
> threads. After the worker threads are running I want the main thread to 
> sleep until a signal (Ctrl-C) arrives. Will it work better when using 
> semaphores?
> 
> Thanks for any hints!
> 
> Bastian Voigt


hi,

maybe you should have a look at the pthread_cond_t doc & usage.
regards

--N

Re: calling mutex_lock() twice from one thread

[Will Bryant]

Bastian Voigt wrote:

> The main thread loads some configuration, then starts some worker 
> threads. After the worker threads are running I want the main thread 
> to sleep until a signal (Ctrl-C) arrives. Will it work better when 
> using semaphores?

Yes, aside from the fact that you want non-recursive locks, semaphores 
are the _only_ synchronization primitive that can be used from inside 
signal handlers.  Note that condition variables most definitely cannot 
be signalled from inside a signal handler - that will break - badly - on 
most unix platforms.

-- 
Will Bryant
Systems Architect, eCOSM.
Phone +64 3 365 4176 | Mobile +64 21 655 443
http://www.ecosm.com/

Re: calling mutex_lock() twice from one thread

[Bastian Voigt]

Will Bryant wrote:
> Yes, aside from the fact that you want non-recursive locks, semaphores
> are the _only_ synchronization primitive that can be used from inside
> signal handlers.  Note that condition variables most definitely cannot
> be signalled from inside a signal handler - that will break - badly - on
> most unix platforms.

Thank you very much. That really helps.