5 ms·

The shrinking role of semaphores

125 points by signa11 4y ago

blakesterz 4y ago
I was just wondering when LWN was started, it feels like it's been around forever... "When LWN was initially designed, at the end of 1997..." I love the content at LWN and that it's STILL going strong for so damn long. It's hard to beat the content there.
- intelVISA 4y ago
  For such a historied site it's maintained great quality, very admirable.
  - binarycrusader 4y ago
    I hope people that admire its quality, and that can afford to, have also chosen to become financial supporters: https://lwn.net/subscribe/ https://lwn.net/subscribe/ I've been a subscriber for a while now.
- Twisol 4y ago
  They almost shuttered in 2002, it looks like! https://lwn.net/Articles/5409/ https://lwn.net/Articles/5409/
colanderman 4y ago
> There is, for example, a binary semaphore that persists in the printk() code because mutex_unlock() cannot be called from interrupt context, while up() can. Interestingly, this oddity is mirrored in userspace, where `sem_post/3` is async-signal-safe, but most other concurrency primitives (e.g. `pthread_mutex_unlock/3` and `pthread_cond_broadcast/3`) are not. (`write/2` and friends is the other notable async-signal-safe concurrency primitive, e.g. in combination with an eventfd or a pipe.)
- tonyarkles 4y ago
  I've been working on a fair bit of RTOS/embedded code recently and we've used a decent number of semaphores for exactly this reason: you can signal a semaphore from an interrupt context. Usually this is being done with a ring buffer where only the interrupt context writes to it and only "userland"[1] reads from it. We initialize the semaphore with an initial value of 0 and a max capacity that matches the capacity of the ring buffer. This lets the userland threads sleep until there's something in the ring buffer without having to worry about trying to use a mutex from inside an interrupt context (which is forbidden). [1] It's not actually userland since it's a Cortex M0 with no MMU, but it's still practical to think of it that way.
kazinator 4y ago
Though invented by Dijkstra, semaphores are ironically the GO TO of synchronization. "The unbridled use of the go to statement has an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress." s/go to statement/semaphore/ -> still holds
- f1shy 4y ago
  I would say the are the assembler of concurrency. You should use higher level abstractions, but sometimes, it has its place.
  - czscout 4y ago
    I agree, I don't tend to think they are quite as dangerous as GOTOs have proven to be, but I do understand the criticism. The example provided about their use in interrupt handlers is of particular relevance.
    - withinboredom 4y ago
      goto isn't that dangerous, or that strange. It has it's place (like inline retries instead of recursion or for-loops) but it's rare to reach for them in most languages.
      - kazinator 4y ago
        Semaphores are like a restricted form of goto which lets you branch exactly, say, two lines forward or two lines back. Building concurrency primitives out of semaphores is like using that goto to build control flow.
        withinboredom 4y ago
        Sounds more like an if-statement than a goto. I catch your meaning though.
    - 4y ago
layer8 4y ago
Does anyone know what the use cases for counting (as opposed to binary) semaphores are in the kernel?
- spc476 4y ago
  There’s one answer in the article itself: "Modules maintainer Luis Chamberlain has recently been working on a problem where the arrival of a large number of requests to load modules in a short time can create difficulties for the memory-management subsystem. After some discussion, he posted a proposal for a mechanism that would simply limit the number of module-load operations that can be underway at any given time. Linus Torvalds quickly answered, reminding Chamberlain that semaphores ('a classic concurrency limiter') could be used for that purpose. The patch has since been reworked along those lines."
Xeoncross 4y ago
I still reach for semaphores (and mutexs) given how simple it is to check an atomic counter. In addition to the linked article (https://lwn.net/Articles/844224/ https://lwn.net/Articles/844224/), are their other good articles on moving to more performant locking or coordination mechanisms?
Glyptodon 4y ago
I've always hated how the operations on semaphores are named, guess I'm too English language oriented.
- kps 4y ago
  What I learned many years ago was the dog analogy: to claim a semaphore, P on it.

125 points by signa11 4y ago

I was just wondering when LWN was started, it feels like it's been around forever... "When LWN was initially designed, at the end of 1997..." I love the content at LWN and that it's STILL going strong for so damn long. It's hard to beat the content there.

intelVISA 4y ago
For such a historied site it's maintained great quality, very admirable.
- binarycrusader 4y ago
  I hope people that admire its quality, and that can afford to, have also chosen to become financial supporters: https://lwn.net/subscribe/ https://lwn.net/subscribe/ I've been a subscriber for a while now.
Twisol 4y ago
They almost shuttered in 2002, it looks like! https://lwn.net/Articles/5409/ https://lwn.net/Articles/5409/

colanderman 4y ago

> There is, for example, a binary semaphore that persists in the printk() code because mutex_unlock() cannot be called from interrupt context, while up() can. Interestingly, this oddity is mirrored in userspace, where `sem_post/3` is async-signal-safe, but most other concurrency primitives (e.g. `pthread_mutex_unlock/3` and `pthread_cond_broadcast/3`) are not. (`write/2` and friends is the other notable async-signal-safe concurrency primitive, e.g. in combination with an eventfd or a pipe.)

tonyarkles 4y ago
I've been working on a fair bit of RTOS/embedded code recently and we've used a decent number of semaphores for exactly this reason: you can signal a semaphore from an interrupt context. Usually this is being done with a ring buffer where only the interrupt context writes to it and only "userland"[1] reads from it. We initialize the semaphore with an initial value of 0 and a max capacity that matches the capacity of the ring buffer. This lets the userland threads sleep until there's something in the ring buffer without having to worry about trying to use a mutex from inside an interrupt context (which is forbidden). [1] It's not actually userland since it's a Cortex M0 with no MMU, but it's still practical to think of it that way.

kazinator 4y ago

Though invented by Dijkstra, semaphores are ironically the GO TO of synchronization. "The unbridled use of the go to statement has an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress." s/go to statement/semaphore/ -> still holds

f1shy 4y ago
I would say the are the assembler of concurrency. You should use higher level abstractions, but sometimes, it has its place.
- czscout 4y ago
  I agree, I don't tend to think they are quite as dangerous as GOTOs have proven to be, but I do understand the criticism. The example provided about their use in interrupt handlers is of particular relevance.
  - withinboredom 4y ago
    goto isn't that dangerous, or that strange. It has it's place (like inline retries instead of recursion or for-loops) but it's rare to reach for them in most languages.
    - kazinator 4y ago
      Semaphores are like a restricted form of goto which lets you branch exactly, say, two lines forward or two lines back. Building concurrency primitives out of semaphores is like using that goto to build control flow.
      - withinboredom 4y ago
        Sounds more like an if-statement than a goto. I catch your meaning though.
  - 4y ago

layer8 4y ago

Does anyone know what the use cases for counting (as opposed to binary) semaphores are in the kernel?

spc476 4y ago
There’s one answer in the article itself: "Modules maintainer Luis Chamberlain has recently been working on a problem where the arrival of a large number of requests to load modules in a short time can create difficulties for the memory-management subsystem. After some discussion, he posted a proposal for a mechanism that would simply limit the number of module-load operations that can be underway at any given time. Linus Torvalds quickly answered, reminding Chamberlain that semaphores ('a classic concurrency limiter') could be used for that purpose. The patch has since been reworked along those lines."

Xeoncross 4y ago

I still reach for semaphores (and mutexs) given how simple it is to check an atomic counter. In addition to the linked article (https://lwn.net/Articles/844224/ https://lwn.net/Articles/844224/), are their other good articles on moving to more performant locking or coordination mechanisms?

Glyptodon 4y ago

I've always hated how the operations on semaphores are named, guess I'm too English language oriented.

kps 4y ago
What I learned many years ago was the dog analogy: to claim a semaphore, P on it.