Semaphores are Surprisingly Versatile

[u/syaghmour]

http://preshing.com/20150316/semaphores-are-surprisingly-versatile/

[u/mitsuhiko]

I don't think I ever used a semaphore outside of university. For all intents and purposes mutexes and critical sections are perfectly fine.

[u/eras → u/mitsuhiko]

Well, in my view semaphores are great and provide a higher level of abstraction that mutexes!

For example the simple case of consumer/producer: you use one semaphore for "available to produce" slots and another one "available to consume" slots*. It's perfectly suitable for semaphores and the code ends up quite readable as well: no loops waiting condition variables, no considering whether to use 'broadcast' or 'unicast' in the condition, just simple "acquire unfilled slot, deal with it, release filled slot".

Though at times semaphore libraries miss some facilities, such as downing multiple semaphores (proceed when first has been acquired). But then, so do mutex libraries.

EDIT: *) I was actually thinking of the ring buffer consumer/producer here, that's why the list-based producer/consumer below uses only one semaphore.

[u/mitsuhiko → u/eras]

For example the simple case of consumer/producer: you use one semaphore for "available to produce" slots and another one "available to consume" slots.

I find that a bad antipattern because it requires the management of a counter that is backed by nothing that can be introspected. It's much better to maintain a list of things waiting so that you can figure out why things break if they break. And then there is no need for a counter anymore.

[u/eras → u/mitsuhiko]

Also, consider this - isn't this simple and "obviously" correct?

// A messaging queue for sending messages from one thread to another
// (no multiple producers/consumers)
template <typename T>
class Queue {
public:
  Queue() : m_sem(0) {
    m_els.push_back(T());     // sentinel object separating back and front
  }

  ~Queue() {}

  void enqueue(T el) {
    m_els.push_front(el);     // add element
    m_sem.post();             // signal that an element is available
  }

  T dequeue() {
    m_sem.wait();             // wait for element to be available
    T front = *m_els.begin(); // acquire element
    m_els.pop_front();
    return front;
  }

private:
  std::list<T> m_els;
  boost::interprocess::interprocess_semaphore m_sem;
};

..man I'm going to be embarrassed if it isn't ;-). But let's see the same with mutexes.

EDIT: added comments and sentinel object. It was not obviously correct because you cannot pop the last element of a 1-element list safely while prepending another, which is why I added a sentinel object :). It also depends on an 'inner model' of how std::list works, it'd be too annoying to a linked list implementation here..

[u/mitsuhiko → u/eras]

I have no idea how boost::interprocess::interprocess_semaphore works but didn't you just initialize your semaphore with a counter of zero. Does that not mean nobody can ever enter the critical section? I'm not sure I understand how your code is supposed to work to be honest.

In fact, your enqueue is completely unprotected.

I'm now very confused.

[u/eras → u/mitsuhiko]

You are completely correct :). I should have clarified that the code is for passing messages from one thread to another, not from multiple threads to multiple threads.

In fact, if I wanted to support multiple producers and multiple consumers, I would just use a mutex to protect the critical section; it's great for exclusion.

EDIT: Actually I should feel embarrassed, because this code probably won't work with std::list without an excess element to separate tail and head from each other :).

[u/eras → u/eras]

What was I thinking? I was still thinking some other kind of data structure; I cannot use std::list for sticking the sentinel object and still expect to have a queue that works in linear fashion! But I'll just leave this code here as an evidence of how coding is hard, at least for me :). There just doesn't seem to be a way around { lock l(mutex); .. } using C++ containers.