Link to home
Start Free TrialLog in
Avatar of raviparu
raviparuFlag for India

asked on

Mutex and Semaphore

This link http://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html states that  “Mutexes can be applied only to threads in a single process and do not work between processes as do semaphores”.

In one of the expert exchange comments on "difference between mutex and semaphore"

it says,  mutex can be used  between threads or processes.

Please explain, if mutex can be used between processes or not ?
ASKER CERTIFIED SOLUTION
Avatar of Infinity08
Infinity08
Flag of Belgium image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of phoffric
phoffric

Across processes you can use a binary semaphore to act similar to mutex in controlling access to critical regions. (There are ownership differences, but that is another topic.)

But, in general, I found some information that talks about shared mutex between processes. Look at discussion on PTHREAD_PROCESS_SHARED in these links:
   http://linux.die.net/man/3/pthread_mutexattr_init
   http://www.embedded-linux.co.uk/tutorial/mutex_mutandis
Across user processes you cannot use mutex as they do not share memory. User applications will have memory violations but kernel modules can use mutex. Semaphores are better as such codes are atomic. Race conditions and deadlocks can be avoided using semaphores...

Mutex Disadvantages
-------------
You cannot use mutexes the same way you can use semaphores: e.g. they cannot be used from an interrupt context, nor can they be unlocked from a different context that which acquired it. [ I'm not aware of any other (e.g. performance) disadvantages from using mutexes at the moment, please let me know if you find any. ]
 
Avatar of raviparu

ASKER

Hello  Tanmay

can you please elaborate the statement above  "mutex cannot be used from an interrupt context"

I read hat there are two types of semaphores

1. counting semaphore:        These doesnt provide mutual exclusion as such, but limit on  the number of threads that can concurrently enter a critical section.

2. Binary semaphore also called as mutex.      These provide the mutual exclusion.Only the lock that holds it should release the lock.


When a counting semaphore is used for a critical section., then whether that critical section should be  re-entrant or not?




When a Semaphore can have a count > 1 (i.e. waiting no of threads) then it is called counting semaphore. Like you mentioned binary semaphore is called binary because here the semaphore can have values 1 or 0 which is quite similar to mutex but the real difference is a mutex will have a owner and it will only let the owner attempt access.

We cannot sleep in interrupt context so we cannot use mutex even I think semaphores also cannot be used that's the reason we use spinlocks..

Cheers...
Hi evilrx,
I uderstand that all three participants are correct. The points must be distributed amoung all three partpcipants

regards
Concur - Recommend that the 4 expert posts be split evenly, especially since the last - http:#33999094 - was a direct response to the author's follow-up question.
>> Please leave your specific (Comment ID) closing recommendations below my post.

http:#33977383 - 25%
http:#33977471 - 25%
http:#33990330 - 25%
http:#33999094 - 25%
The question, the only question, was: "Please explain, if mutex can be used between processes or not ?".

The only post to address this directly was http:#33977383

http:#33977471 does not answer this question. If provides other information, but it does not answer this question.

http:#33990330 discusses the differences between user and kernel memory but does not answer the question asked.

http:#33999094 is a follow up to questions raised by the previous post that raised points not related to the actual question.

People, it's all very well posting additional information into a question but don't be surprised when it comes to clean-up when the CV only chooses the one answer that actually addresses the question asked. In other words, by all means post if you feel you are adding something of value but do so for a willingness to be helpful and not for points because when it comes to clean-up we are only going to select the answer(s) that addressed the actual question asked.

My final recommendation is still as it was to start with, Accept: Infinity08 (http:#33977383) as this is the only post to directly address the actual question asked.

evilrix
Experts-Exchange Cleanup Volunteer

OP: >> "Mutexes ... do not work between processes"

http:#33977471 : >> "mutex between processes"
Question addressed.
Paul, when quoting please quote in full.

"But, in general, I found some information that talks about shared mutex between processes."

That is not answering the question - that is providing additional information but the actual question was answered by Infinity08 in the very first post.
>> "That is not answering the question  - that is providing additional information"

OP: >> "if mutex can be used between processes or not ?"
Indeed, the additional information provided answers this question in a very specific manner.
raviparu seemed to be confused about two statements that seemed to contradict each other on first sight.

I explained that both statements are correct in their own context, because it depends how the mutex/semaphore you're talking about is implemented. Imo that should have been enough to take away any confusion, and thus answer the question.

No doubt, the extra information is interesting, but it seems it wasn't really necessary to answer the question. In fact, it looks like the extra information actually added to the confusion, given the author's follow-up post.
(1)  >> What that link describes, are pthread mutexes.
(2)  >> But other libraries might implemented mutexes differently.

(2) Agree
(1) Statement of fact. But this statement seems to have an implication whether intended or not. When coming across this answer in the PAQ, a reader may likely make an incorrect inference which may be incorrect. Recommend making any implication explicit.

>> Recommend making any implication explicit.

Your statement seems to imply the possibility of an incorrect implication ;) Care to explain what "incorrect inference" you're referring to ? Just so i can avoid it in the future ?
If (1) were standalone, then I infer following implication: Statement from link is correct:
"One can apply a mutex to protect a segment of memory ("critical region") from other threads. Mutexes can be applied only to threads in a single process and do not work between processes as do semaphores."
Is this inference intended?

Adding statement (2) may open a relationship with (1). Are "other libraries", just non-POSIX libraries (one inference), or could it mean that there may be some other POSIX libraries that do allow mutex to be applied to threads of different processes (another inference)?

Also, for a question of this nature, I think some supportive references would be useful to at least try to show a consensus of authorities.
It looks like you're over-analyzing this.

The question mentioned two seemingly conflicting statements :

(a) the first statement was taken from http://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html, which deals specifically with pthreads (which is what I pointed out by saying "What that link describes, are pthread mutexes.")

(b) the second statement was taken from some unspecified comment somewhere on Experts Exchange. Since I have no idea what comment the author was referring to, I couldn't make a specific analysis of it. Either that comment was incorrect/incomplete, or it was talking about another type of mutex. Hence I said "But other libraries might implemented mutexes differently."

Apart from the spelling mistake in "implemented" I see nothing wrong, incomplete or misleading in what I posted.

I'll leave it up to the moderators to judge on this now. All this extra arguing seems to be pointless.
I added my comments because the links in http:#33977471 deal with pthreads and contradict the link in the OP.
>> It looks like you're over-analyzing this.
I know that http:#34275210 looks like over-analyzing :) When I first read the first post, I was not analyzing at all. I read "What that link describes, are pthread mutexes." and immediately inferred (whether intended or not) that the link in the OP is correct for phthread mutexes. After finding contradicting references, I thought that you might be infering something else with "But other libraries might implemented mutexes differently.", and that my initial inference was incorrect. So, for the benefit of the PAQ, I added my post.
They don't contradict them - they deal with a different version/implementation of pthreads. Which strengthens my statement "But other libraries might implemented mutexes differently.".
All,
 
Following an 'Objection' by expert_tanmay (at https://www.experts-exchange.com/questions/26641667/08-Dec-10-05-Automated-Request-for-Review-Objection-to-Accept-Q-26566229.html) to the intended closure of this question, it has been reviewed by several Moderators, Zone Advisors and Experts, and is being closed as per those discussions.
 
At this point I am going to re-start the auto-close procedure.
 
Thank you,
 
SouthMod
Community Support Moderator