14

(I think that) the consensus number for a mutex is 2.

What is the consensus number for semaphores (like in pthread_sem_*)?

What is the consensus number for condition variables (like in pthread_cond_*)?

Giovanni Funchal
  • 8,934
  • 13
  • 61
  • 110

4 Answers4

10

The consensus number for a mutex would be 1. It's trivially clear that a mutex will be wait-free for a single thread. From its definition, it's also clear that a mutex is no longer wait-free for two threads. The consensus number therefore is >=1 and <2, so it must be 1.

Likewise, other synchronization mechanisms that work by halting one thread in favor of another also have consensus number 1, and therefore cannot be used to construct a wait-free object shared by 2 threads.

MSalters
  • 173,980
  • 10
  • 155
  • 350
4

The answer depends on the supported operations on the mutex or the semaphore. If only blocking locks are supported, the consensus number is 1. If a thread can try to lock the mutex without waiting, the consensus number is 2. That is because if there are two threads, both can try to lock the mutex, both can agree which one got it, so there is consensus. If the mutex can additionally determine, for any number of threads, which thread has locked it, then the consensus number is infinite. I think the situation for semaphores is similar. Mutexes are equivalent to semaphores with the counter 1. I don't think consensus can be reached just with larger counters, it still comes down to the same operations. Pthreads supports non-blocking locks but not queries, so there the answer would be 2.

Signaling a condition variable does nothing if any threads are not waiting for it, so they have consensus number 1.

Juho Östman
  • 1,544
  • 1
  • 12
  • 20
3

Infinite, surely? But they're not wait free.

Perhaps I'm misunderstanding. You say a mutex has a consensus number of 2 - what's your source for that? It's designed to allow any number of threads to share a resource, with the trade-off of blocking.

Atomic test-and-set has a consensus number of 2, but doesn't block.

To clarify: semaphores, mutexes, etc. are primitives that you can simply wrap around a shared resource to make it safe (as long as you do it correctly). They may block, but they will guarantee your data is safe.

The paper you cite is about the primitives needed to protect data without blocking, which is hard. The same primitives may be useful for locks as well, but that's just a nice extra.

Mark
  • 6,269
  • 2
  • 35
  • 34
  • You are perhaps right... I think a mutex has consensus number of 2 because I can implement it with test&set ONLY. I don't think it is possible to implement a semaphore with mutexes ONLY. I need something stronger than that like condition variables. – Giovanni Funchal Apr 22 '09 at 09:48
  • So the "minimum" consensus number of a mutex is 2. What is the "minimum" consensus number of a semaphore ? – Giovanni Funchal Apr 22 '09 at 12:28
  • But that implementation of a mutex won't be wait-free. You'll spin on the TAS instruction. – Mark Apr 22 '09 at 12:31
  • (sorry, accidentally deleted that comment) – Mark Apr 22 '09 at 12:32
  • I must confess, I've only skim-read the paper, but it's about analysing wait-free synchronisation. I don't think consensus number is really relevant to anything that blocks. – Mark Apr 22 '09 at 12:40
  • If you want to know more about the cases that dictate different implementations of synchronisation, take a look at http://en.wikipedia.org/wiki/Peterson%27s_algorithm and its "See also" articles – Mark Apr 22 '09 at 12:50
0

From this article alone you can conclude that a semaphore must have a consensus number less than or equal to 2. Here's why:

On the third page of the article they state: "The fetch&add operation is quite flexible: it can be used for semaphores...". Since we know that fetch&add has consensus number equal to 2, Theorem 1 of that paper can then be used to show that a semaphore must have consensus number less than or equal to 2. The proof goes like this:


Proof

Assume that a wait-free implementation of semaphores by fetch&add exists. Further assume that a semaphore has consensus number greater than 2. We know that fetch&add has a consensus number of 2. From Theorem 1 we can conclude that there exists no wait-free implementation of a semaphore by fetch&add in a system of more than 2 processes. This contradicts the assumption that an implementation by fetch&add exists. Therefore, a semaphore must have a consensus number less than or equal to 2.

QED

Community
  • 1
  • 1
Waylon Flinn
  • 19,969
  • 15
  • 70
  • 72
  • Hmm.. I'm pretty sure you cannot implement semaphores with mutexes, you also need condition variables or some other way to atomically unlock a mutex and enter a queue. – Giovanni Funchal Apr 22 '09 at 09:45
  • The last step doesn't follow. I could implement a mutex with compare-and-exchange. Does that make it infinite? Or I could implement a mutex with just a set, which would only be safe for one process. The point of the paper is to investigate non-blocking primitives, which a mutex is not. – Mark Apr 22 '09 at 12:29
  • @Helltone The proof does not rely upon the implementation of semaphores with mutexes; It relies upon the fetch&add. However, you're wrong: you can implement semaphores with mutexes. http://www.picturel.com/ucr/node32.html. I don't see why reliance upon a condition variable for the implementation means you can't implement it. – Waylon Flinn Apr 22 '09 at 13:22
  • @Mark You have it backward. If you can implement X using only Y, it proves that the consensus number of Y is at most the consensus number of Y. The proof correctly states that since you can implement semaphores using fetch-and-add, and the consensus number of fetch-and-add is 2, the consensus number of semaphores is ≤2. Likewise, since you can implement a mutex with compare-and-exchange, the consensus number of mutexes is _at most_ the consensus number of compare-and-exchange. – Gilles 'SO- stop being evil' Nov 24 '21 at 10:17
  • As far as I can tell, condition variables do increase the consensus number to 2, compared to just 1 with mutexes alone. I'm looking for a reference right now. – Gilles 'SO- stop being evil' Nov 24 '21 at 10:18
  • @Gilles'SO-stopbeingevil' The problem with the proof is it uses the assumption that an implementation using fetch&add exists to both limit the consensus number and prove that an implementation doesn't exist. As I said previously, this is about wait-free primitives, so talking about a semaphore's consensus number is meaningless. I agree with the accepted answer that it is wait-free for a single thread, but nothing in the definition of consensus number in this paper strictly requires it to be wait-free so I'm not sure about extending it. – Mark Nov 25 '21 at 14:51