LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Reply
 
Search this Thread
Old 08-14-2005, 11:03 PM   #1
George2
Member
 
Registered: Oct 2003
Posts: 354

Rep: Reputation: 30
About Lock And Unlock


Hello everyone,


Suppose several threads are trying to enter into a region, which is protected by a mutex to allow only one thread in such region, and then one of them is luckily selected to enter into the region while others are locked from entering the region.

Suppose sometime later, the lucky thread exits the region, and then without calling pthread_cond_signal, simply calling unlock (as the last statement) to exit the region. I am wondering whether the waiting locked thread will know the status -- the mutex is unlocked and it is ready for a thread to try to enter the region -- immediately. If not, it seems that the waiting threads will continue to wait so that the performance is not very good.

I am sure that calling pthread_cond_signal will let the waiting locked threads know immediately the status, but not sure what will happen if we do not call pthread_cond_signal and simply call unlock, as I mentioned above.

Could anyone help please?


regards,
George
 
Old 08-15-2005, 04:21 PM   #2
Mara
Moderator
 
Registered: Feb 2002
Location: Grenoble
Distribution: Debian
Posts: 9,535

Rep: Reputation: 148Reputation: 148
It depends if it all runs on one or more processes. If there are more, there's still a huge chance all the threads will be running on one, but it may be different. Now, when they're all using one processor, there's only one thread running at a time. So the other ones may 'notice' the change only when they're run. By scheduler, after the one running is stopped (whatever reason). I don't remember at this time if unclock runs scheduler. It may.
 
Old 08-15-2005, 09:10 PM   #3
George2
Member
 
Registered: Oct 2003
Posts: 354

Original Poster
Rep: Reputation: 30
Thanks Mara,


Quote:
Originally posted by Mara
It depends if it all runs on one or more processes. If there are more, there's still a huge chance all the threads will be running on one, but it may be different. Now, when they're all using one processor, there's only one thread running at a time. So the other ones may 'notice' the change only when they're run. By scheduler, after the one running is stopped (whatever reason). I don't remember at this time if unclock runs scheduler. It may.
Your reply is very helpful. I am wondering why "So the other ones may 'notice' the change only when they're run". Why only when?

So your point is that it is not sure that whether or not calling pthread_cond_signal will be more efficient than not calling it when a thread unlocks a region. But if unlock runs scheduler, it will be the same. Am I correct?

I am wondeirng whether the activities of unlock and pthread_cond_signal, which I am concerning on this topic, is standard or formally documented anywhere.


regards,
George

Last edited by George2; 08-15-2005 at 09:12 PM.
 
Old 08-16-2005, 09:16 AM   #4
sundialsvcs
Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 5,268

Rep: Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086
If another thread is waiting for the mutex to be unlocked, it will wake-up when the unlock occurs. If no one is waiting for the mutex, no one knows (or, presumably, cares...) that the mutex has just been unlocked.

The purposes of a condition variable and that of a mutex are not the same. A condition-variable is a sentinel that indicates, to anyone who may be waiting for it, that "something interesting may have just happened." A mutex is a locked room that allows only one process to enter at a time.

I say "may have" just happened because it is possible that a process will wait for the condition and find out that there is not, in fact, anything for it to do. But that's okay. We don't mind if the process winds up taking a few extra, empty cycles. What we don't want to allow is "infinite wait," or deadlock, where everyone is Waiting For Godot.

It is often the case that there is a thread which performs services asynchronously for other threads, using some shared control-block to (say) describe the next request or to maintain a queue of pending requests. This thread will use a mutex to synchronize access to the control-block (which must be accessed both by the server and by requestors), and a condition-variable to signal to the server that there might be more work for it to do. When the server finishes a request and wants to wait for more, pthread_cond_wait() is exactly the sort of sequence that the server needs to do, and this call binds the usual three-step sequence up neatly in just one call instead of three.
 
Old 08-16-2005, 09:23 PM   #5
George2
Member
 
Registered: Oct 2003
Posts: 354

Original Poster
Rep: Reputation: 30
Thanks sundialsvcs,


Quote:
Originally posted by sundialsvcs
If another thread is waiting for the mutex to be unlocked, it will wake-up when the unlock occurs. If no one is waiting for the mutex, no one knows (or, presumably, cares...) that the mutex has just been unlocked.


Your reply is very helpful. So you mean when a thread calling unlock mutex, whether or not calling pthread_cond_signal, the waiting threads on the mutex will be notified immediately. Am I correct? I am wondering whether this feature is documented in any pthread standards or formal documents.

Quote:
Originally posted by sundialsvcs
The purposes of a condition variable and that of a mutex are not the same. A condition-variable is a sentinel that indicates, to anyone who may be waiting for it, that "something interesting may have just happened." A mutex is a locked room that allows only one process to enter at a time.

I say "may have" just happened because it is possible that a process will wait for the condition and find out that there is not, in fact, anything for it to do. But that's okay. We don't mind if the process winds up taking a few extra, empty cycles. What we don't want to allow is "infinite wait," or deadlock, where everyone is Waiting For Godot.
A very good description! What do you mean "find out that there is not, in fact, anything for it to do" and "winds up taking a few extra, empty cycles"? Could you provide a simple sample please?

Quote:
Originally posted by sundialsvcs
It is often the case that there is a thread which performs services asynchronously for other threads, using some shared control-block to (say) describe the next request or to maintain a queue of pending requests. This thread will use a mutex to synchronize access to the control-block (which must be accessed both by the server and by requestors), and a condition-variable to signal to the server that there might be more work for it to do. When the server finishes a request and wants to wait for more, pthread_cond_wait() is exactly the sort of sequence that the server needs to do, and this call binds the usual three-step sequence up neatly in just one call instead of three.
I think it is a very typical model in almost all software design. I want to reuse this model in the future. Do you know where can I find simple sample source codes of this model? Any programming language is ok.


regards,
George

Last edited by George2; 08-16-2005 at 09:26 PM.
 
Old 08-17-2005, 02:10 PM   #6
sundialsvcs
Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 5,268

Rep: Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086
When you unlock a mutex, if there are other threads that are waiting for this mutex to be unlocked, the first-in-line thread will be awakened. Otherwise nothing more happens.

A condition-variable simply serves to wake-up someone who's waiting on it... to get them out of their sleep and to start them running again. Another way of looking at them is rather in-reverse: a condition-variable is a construct that exists in order to enable a thread to reliably sleep during the times that it is known that it does not have any work to do.
 
Old 08-18-2005, 02:26 AM   #7
George2
Member
 
Registered: Oct 2003
Posts: 354

Original Poster
Rep: Reputation: 30
Thanks sundialsvcs,


Quote:
Originally posted by sundialsvcs
When you unlock a mutex, if there are other threads that are waiting for this mutex to be unlocked, the first-in-line thread will be awakened. Otherwise nothing more happens.
Your reply is very helpful. What do you mean "first-in-line thread"? Could you provide me a simple sample please?


regards,
George
 
Old 08-23-2005, 10:30 AM   #8
sundialsvcs
Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 5,268

Rep: Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086
It's a queue, okay? A waiting-list. The first guy in line gets to go. The rest continue to wait. Just like in the real world.
 
Old 08-23-2005, 11:30 PM   #9
George2
Member
 
Registered: Oct 2003
Posts: 354

Original Poster
Rep: Reputation: 30
Thanks sundialsvcs,


Quote:
Originally posted by sundialsvcs
It's a queue, okay? A waiting-list. The first guy in line gets to go. The rest continue to wait. Just like in the real world.
Your reply is very helpful.

Quote:
Originally posted by sundialsvcs
When you unlock a mutex, if there are other threads that are waiting for this mutex to be unlocked, the first-in-line thread will be awakened. Otherwise nothing more happens.

A condition-variable simply serves to wake-up someone who's waiting on it... to get them out of their sleep and to start them running again. Another way of looking at them is rather in-reverse: a condition-variable is a construct that exists in order to enable a thread to reliably sleep during the times that it is known that it does not have any work to do.
I am sorry that I have not made myself understood. My question is not whether waiting threads will be awaken up to proceed. My queston is that,

1. Calling both pthread_mutex_unlock and pthread_cond_signal will let the waiting locked threads know immediately the status. Am I correct?
2. What will happen if we do not call pthread_cond_signal and simply call pthread_mutex_unlock? Will the waiting threads know immediately about the status (can proceed to execution)?


regards,
George
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
E: Could not get lock /var/lib/dpkg/lock - open (11 Resource temporarily unavailable) phreakshew Linux - Newbie 16 02-15-2012 12:28 PM
Lock screen (requiring password to unlock) when resuming from suspend theoldman Linux - Laptop and Netbook 2 12-17-2009 09:35 PM
Caps Lock & Scroll Lock Flashing thedug Linux - General 6 06-07-2008 09:43 PM
Caps Lock and Num Lock leds dont work! npc Linux - Hardware 2 11-08-2005 10:40 AM
RedHat 9.0 freezes with blinking Caps lock and Scroll lock queen-bee Linux - Software 0 07-30-2004 10:40 PM


All times are GMT -5. The time now is 11:57 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration