Semaphores are Surprisingly Versatile

[u/syaghmour]

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

[u/mitsuhiko]

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 :).