3

I think lock, mutex, semaphore are used for synchronized multiple (threads or processes?) to access something simultaneously.

Must this "something" be some shared memory between multiple (threads or processes)?

If yes, does that mean lock, mutex, semaphore are only used for multiple threads of a process, not for multiple processes, because multiple processes don't share memory, while multiple threads of the same process do?

Thanks.

  • The idea of the difference between a thread and a process on Linux (and some other systems) can be a bit fuzzy. For example 2 processes can share memory. – ctrl-alt-delor Aug 10 '14 at 22:34
  • lock, mutex, semaphore, monitors etc are used to synchronize, so that two threads do not access the resource at the same time. – ctrl-alt-delor Aug 10 '14 at 22:35
5

Are lock, mutex, and semaphore for between threads or between processes?

You'll find examples of locking primitives for both situations. For example, pthread mutexes are used for mutual exclusion between threads of the same process. On the other hand, System V IPC (man svipc) semaphores can be used across processes. Filesystem-level locks (on files or parts of files) can also used to coordinate between multiple processes.

Must this "something" be some shared memory between multiple (threads or processes)?

Not necessarily shared memory. Any sort of resource can be protected with synchronization primitives. A piece of shared memory (shared between processes and/or threads) is perhaps the most common example, but other things like file-handles (locking a whole file, or parts of a file, or other sorts of "handles" to unique resources) and access to hardware devices are also possible.

If yes, does that mean lock, mutex, semaphore are only used for multiple threads of a process, not for multiple processes, because multiple processes don't share memory, while multiple threads of the same process do?

Well no. Processes can share memory. (And in fact most of them do, if only in a read-only fashion - pages containing shared library code are shared between processes. That doesn't need protection though. Copy-on-write shared mappings done when forking do need protection, but the kernel handles that transparently - this involves locks on shared memory mappings, which is conceptually a bit different from ordinary locks protecting a memory region/datastructure.)

Anything else that processes or threads can share (when at least one of them can write) needs protection/coordination, files and devices being the two most common I think.

  • filesystem-level object (plain file, directory or lock this should be " block ", and for easier google searches referred to as lock granularity. – Dani_l Aug 9 '14 at 21:27
  • 1
    @Dani_l: not what I meant. File locking primitives (flock) are examples of locks you can (sometimes) use across processes. You can organize exclusive access based on directory creation (usually, and maybe on file/inode creation depending on lots of stuff). I'm not talking about locking a file, directory or a disk block, I'm talking about things you can use as locking primitives. – Mat Aug 9 '14 at 21:37
  • The OP asked for locks to allow concurrent access to stuff other than memory. I assumed you answered about concurrent write access features of distributed/clustered filesystems, with block level locking as the "lock" that allows that. My bad. (and see wiki.lustre.org/lid/agi/agi_ldlm.html#_lock_type_and_mode ) – Dani_l Aug 9 '14 at 21:54
  • @Dani_l: you're right, I misread the question. Edited, hopefully got the right idea this time. (And no I don't want to go into that level of detail. Feel free to write an answer if you do.) – Mat Aug 10 '14 at 8:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.