In linux code, I remember hearing there is a full memory barrier around mutex_lock(). I want to make sure whether it is around sem_xxx also.
Asked
Active
Viewed 1,223 times
7
-
Well seeing as they're implemented using each other yes. – Jesus Ramos May 08 '13 at 02:28
-
2@JesusRamos: mutex and semaphore are not implemented using each other. Both are implemented separately. They do both use atomic increment/decrement and futex however. – Andrew Tomazos May 08 '13 at 02:31
-
I wrote that wrong, I meant using the same thing. – Jesus Ramos May 08 '13 at 02:37
-
Related: [How does a mutex lock and unlock functions prevents CPU reordering?](https://stackoverflow.com/q/50951011) describes how compile-time reordering is also prevented. – Peter Cordes Jan 23 '19 at 19:45
2 Answers
13
The authoritative answer is here:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11
Applications shall ensure that access to any memory location by more than one thread of control (threads or processes) is restricted such that no thread of control can read or modify a memory location while another thread of control may be modifying it. Such access is restricted using functions that synchronize thread execution and also synchronize memory with respect to other threads. The following functions synchronize memory with respect to other threads: ...
sem_wait and sem_post are in the list, so they are full memory barriers.
R.. GitHub STOP HELPING ICE
- 208,859
- 35
- 376
- 711
1
Yes, it uses an atomic increment/decrement in the uncontended case, which of course has a membar. For the contended case there is a system call to futex, which also has a membar.
Andrew Tomazos
- 66,139
- 40
- 186
- 319
-
2This answer is implementation-specific and does not give the reason why they're full barriers. – R.. GitHub STOP HELPING ICE May 08 '13 at 02:51
-
@R.: The question is tagged `linux`, and starts "In linux code,". He didn't ask why, he simply asked if they do or not. – Andrew Tomazos May 08 '13 at 04:18
-
2Even for Linux, the answer would involve whether they're documented as such, not whether the implementation (which might change) happens to involve a barrier. – R.. GitHub STOP HELPING ICE May 08 '13 at 04:33
-
@R.: It's a silly distinction to make in this case. I'm not even sure how you would implement a semaphore or mutex without a membar. – Andrew Tomazos May 08 '13 at 06:59
-
Indeed, as x86 has very strong memory ordering, it's almost impossible to arrange for memory not to be synchronized when the flow of execution is synchronized, and probably fully impossible if any atomic (lock-prefixed) instructions are involved. – R.. GitHub STOP HELPING ICE May 08 '13 at 07:03
-
@R.: This question is not tagged x86. The point is that for a mutex to do its job, it has to be a memory barrier, even if that costs extra instructions like it does on most non-x86 ISAs. – Peter Cordes Jan 23 '19 at 19:47
-
@PeterCordes: The comment you're replying to is a reply to Andrew's speculation that you couldn't implement the basic sequencing properties, without any regard to how views of other memory are affected, without using a barrier; I was noting that this may be true on x86 (but not in general). Of course to implement the specified behavior ("synchronizing memory") you do need a barrier, which is what my answer addresses - that this is not a matter of implementation details but the requirements of the specification. – R.. GitHub STOP HELPING ICE Jan 24 '19 at 00:29