I'm learning about pthreads and signals in an OS class, and I had a question: is the underlying signalling mechanism of pthread_cond_signal just a standard POSIX real-time signal that has been fit to the task of waking waiting threads? Or is it some other mechanism that happens to use the same term to describe two different ideas?
If they are the same, I should be able to tell a thread to wake from pthread_cond_wait using pthread_kill, right? And could I somehow change a thread's signal mask so that it doesn't receive the signal from pthread_cond_signal when it should? I realize these are bad coding practice and hack-y sorts of things to try, but I just want to understand the underlying mechanics of the pthread wait/signal process.
I tried reading the algorithm here, but it went a bit over my head. My guess is that they are different, but I just want to make sure.
Though the term "signal" is used when speaking of both mechanisms, POSIX realtime signals and pthread condition variables are different.
POSIX or operating signals are "software interrupts" with relatively rich semantics and history. They may be ignored (SIG_IGN), delivered (sa_sigaction), accepted, or blocked, except when they can't be. They may have their own stack for user-defined disposal, though what one can safely do during disposal is quite limited. They might take aim at an individual thread or at a whole process. They interrupt some functions, but not others, sometimes at the end-user's discretion (SA_RESTART). Realtime extensions allow signals to queue and perhaps deliver a word of data. There's more.
By contrast, POSIX pthread condition variables are synchronization mechanisms protecting some predicate. Here, the "signal" is the user-initiated action of waking one thread waiting on the condition variable, if such a thread exists.
It's perhaps unfortunate that the same term is used in different senses when we talk about these mechanisms, but so it is.