0
CodeBlockA;

Lock;
CodeBlockB;
Unlock;

CodeBlockC

Code block may contain a lot of code, just take it as a unit.

Is CodeBlockA CodeBlockB CodeBlockC always execute in serial? How lock achieve this？

Karl
  • 665
  • 4
  • 19
  • 1
    I believe so. Have a look at [this](https://stackoverflow.com/a/28772117/6874310). – Jardel Lucca Jul 29 '21 at 20:14
  • It depends what you mean by "in serial". Within a single thread, it may not actually be serial in certain senses, but unless you cause UB, the observable behavior of the code will be precisely as if it were. If the effects of the code blocks can be seen by other threads, they may or may not observe those effects in order, unless the locks include appropriate memory barriers. Look up "C memory ordering". – Nate Eldredge Jul 29 '21 at 23:32
  • 1
    lock/unlock only makes sense if you run multiple threads or processes. Relatively to those it can run in parallel or in any sequence. However, within a single thread or a process the order of execution cannot change. So, your code is executed as it is written, unless your 'lock/unlock' means something else. – Serge Jul 30 '21 at 00:44

1 Answers1

0

Now, i don't know about other systems but on linux it is like this:

pthreads

In NPTL, thread synchronization primitives (mutexes, thread joining, and so on) are implemented using the Linux futex(2) system call.

futex

When executing a futex operation that requests to block a thread, the kernel will block only if the futex word has the value that the calling thread supplied (as one of the arguments of the futex() call) as the expected value of the futex word. The loading of the futex word's value, the comparison of that value with the expected value, and the actual blocking will happen atomically and will be totally ordered with respect to concurrent operations performed by other threads on the same futex word. Thus, the futex word is used to connect the synchronization in user space with the implementation of blocking by the kernel. Analogously to an atomic compare-and-exchange operation that potentially changes shared memory, blocking via a futex is an atomic compare-and-block operation.

C - mtx_lock

Prior calls to mtx_unlock on the same mutex synchronize-with this operation, and all lock/unlock operations on any given mutex form a single total order (similar to the modification order of an atomic)

C Standard n2596

7.26.4 Mutex functions

For purposes of determining the existence of a data race, lock and unlock operations behave as atomic operations. All lock and unlock operations on a particular mutex occur in some particular total order.

NOTE This total order can be viewed as the modification order of the mutex.

Erdal Küçük
  • 4,810
  • 1
  • 6
  • 11
  • The memory access in nearby code block also has a total order？ – Karl Jul 30 '21 at 00:52
  • I would say no. Therefore you have to synchronize (or build barriers). But as the futex doc explains it, the 'modification' of the mutex variable (loading, comparison and actual blocking) is guaranteed to be ordered. Above and beyond a lock/unlock not. – Erdal Küçük Jul 30 '21 at 01:10