Hacker News Reader

For those wondering, P comes from 'Passering', roughly translated 'pass' (as a noun), and V from 'Vrijgave' ('release'). Apparently somehow this terminology comes from train systems but there's not a lot of context on that etymology.

As an aside, this paper (it's actually the transcription of a lecture) has some great metaphors that explain problems with concurrence and issues with synchronisation. At the risk of losing much of the nuances, he essentially illustrates the synchronisation using the example of a teacher who needs to find a pupil in a class. When pupils are free to choose a seat, she needs to scan all seats when she is looking for a particular pupil; but when at the same time pupils are free to change seats as she's scanning, there is no guarantee that she will ever find the pupil she's looking for as he might run from the back of the class to the front as soon as she's done scanning the front.

From what I've heard, the P comes from "Probeer" (to "try"), and the V from "verhoog" (increase).

This makes more sense to me.

That seems the correct one : https://cs.nyu.edu/~yap/classes/os/resources/origin_of_PV.ht...

You're referring to https://cs.nyu.edu/~yap/classes/os/resources/EWD74.pdf while 'passering' and 'vrijgave' are already mentioned in http://www.cs.utexas.edu/users/EWD/ewd00xx/EWD35.PDF

Ah thank you. Fun read.

That's Dijkstra's later terminology. In EWD35 he introduced the operations as "passering" and "vrijgave". Then in EWD51 he uses "verhogen" and the neologism "prolagen" ("probeer te verlagen"). In EWD74 he switches to "proberen".

These documents are available from the Dijkstra archive: http://www.cs.utexas.edu/users/EWD/welcome.html

IIRC the analogy is to the positions of a stop/go safety flag (or an actual railway semaphore https://en.wikipedia.org/wiki/Railway_semaphore_signal !) meant to ensure that only one train is in a railway tunnel at a time. A Dutch-speaker with EWD35 http://www.cs.utexas.edu/users/EWD/ewd00xx/EWD35.PDF should be able to confirm this.

I think that much is clear, (the railway analogy), but the idea that tunnels are the main use case for semaphore signals is daft. All railways use variations on the principle of block signalling, where only one train is allowed on any section of track, even if successive trains are travelling in the same direction. This ensures safe separation of trains, which take some distance to stop.

An amusing anecdote I heard about this a few weeks ago: he came up with "P" and "V" when explaining the concept to his students at Eindhoven University. He looked outside the window of the classroom he was teaching in and saw the name of the local soccer club on a nearby stadium which is PSV.

That anecdote is amusing, but it seems unlikely things worked exactly like that. They are near each other in the center of town, but the stadium and the university are a kilometer apart and separated by an elevated railway. At the time EWD35 was written (prior to 1963) the stadium had just installed 40 meter lights, so while it's possible the initials were written on the back of these, it seems more likely that this is a fanciful urban legend. Do you have any more information?

> This stuff was all well understood four decades ago. Much of it was forgotten outside the mainframe world, because threads and multiprocessors didn't make it to microprocessors for several more decades.

Here's an important distinction to make: this stuff was well understood in theory, but the practice is a bit different.

Semaphores are a neat theoretical concept but not a very good practical parallel programming paradigm. Semaphores are easy to reason about when writing proofs by induction that a parallel programming algorithm is working correctly, which is why they are still at the core of parallel programming education.

But when writing practical multithreaded programs, mutexes and condition variables are a lot more practical. Typically each mutex is coupled with one or more condition variables to wait/signal for conditions such as "queue not full" and "queue not empty". Incrementing and decrementing numeric counters is a very clumsy way to maintain a state of any kind. Implementing a semaphore requires grabbing a spinlock and doing this several times is unnecessary when you could just grab one mutex, check for the appropriate condition(s) and then wait/signal on the correct condition.

It is rather unfortunate that parallel programming is still primarily being taught in the theoretical manner (at least I was) using primarily semaphores, leaving too little emphasis on the practical implementation. It is important to understand the theory and know how to do the proofs but it is equally important to apply this into practice.

Every time I see someone "implement" a semaphore using a pthread mutex and condition variable, I cry a little. I've seen this several times in production code.

> It's very simple. That's the real use case for P and V. Linus' note indicates that in 1999 he didn't know this.

I'm pretty sure Linus was joking and he did understand what semaphores are used for. Every computer science curriculum has a course on parallel programming with bounded buffer producer consumer/problems, readers/writers problems and other "toy problems" solved using semaphores, followed by proof by induction that the solution is correct. And Linus did, eventually, finish a degree on computer science.

Semaphores are useful for rate limiting - for example say you have a connections pool with an upper bound, so naturally the number of threads that can acquire a connection and do things with it is limited by the size of that connections pool.

And you don't necessarily need a mutex or to actually put the thread to sleep. Semaphores are also relevant when speaking of asynchronous stuff (e.g. Futures), in which case you can easily do CAS operations on an atomic reference holding an immutable queue of promises. Slightly inefficient under high contention, but non-blocking and gets the job done.

While I do not disagree with you, I still do think that even these cases mutexes and conditions are more practical.

Take the "rate limiting" example you mention (also one of Linus' examples in the OP). You initialize a semaphore to `max_concurrent_connections` and call `semaphore_down()` when you enter the connection handling sequence and `semaphore_up()` when you're done. Now this works fine and is an idiomatic example of using semaphores.

However, in the real world, this kind of situation rarely happens in isolation. What happens if you need to terminate the application for whatever reason, and do so cleanly? If you're under contention, you might have a dozen threads waiting for the semaphore go up and your only option is to kill them. Or implement some logic for this case (using another semaphore) to make sure the application hasn't been terminated while we were waiting for the rate limiting semaphore.

You can implement this cleanly using mutexes and conditions, by creating a "killable semaphore" synchronization primitive. While this is similar to a semaphore as an idea, it's very difficult to implement it if semaphores are the only primitive you have. Additionally, you probably want some kind of timeout if the queue is full.

So in practice you need something like:

    while(true) {
        socket = accept();
        int status = rate_limiting_enter(my_rate_limiter);
        // NOTE: someone else may call rate_limiting_terminate()
        if(status == OK) {
            service(socket);
            rate_limiting_leave(my_rate_limiter);
        } else if(status == TIMEOUT) {
            send_busy(socket);
        } else if(status == KILLED) {
            send_terminate(socket);
            break;
        }

        close(socket); // this must be called or resources leak
    }

Now, while this is theoretically very similar to a semaphore, it has other real world priorities (like timeout and termination) which are very difficult to implement using Dijkstra -style semaphores with only P() and V() operations (and you definitely need more than one semaphore).

This has been the case in almost every practical multithreaded programming scenario I've had. The solution could be thought of using semaphores (and I frequently do) but in practice, there's always some real world conditions (timing, contention, errors) that must be met.

It is very trivial to implement semaphore-like synchronization primitives using mutexes and conditions but not vice versa.

Semaphores are very good for textbook examples and a mental model but not so much in practical software.

Termination in queued systems is moderately hard. You have to drain out the queues. In Go, you can close a channel at the write end and wait for the reader to reach EOF. But if the reader is stuck waiting for something, there's a problem. Especially if it's waiting to write another channel. If you close a channel written by another task, that task will panic when it writes to the closed channel. You can't close channels to force shutdown in Go unless a panic is acceptable.

This is a classic problem with bounded buffers, re-invented four decades later.

Using two semaphores to implement a bounded buffer has the advantage that writers and readers don't interfere with eachother until the queue is either empty or full. Of course, that might be the only good use of semaphores, and a direct implementation can be better then one using standard semaphores.

Semaphores can be implemented in a way that doesn't require a spinlock in the fast path. Still not as fast as you can make a mutex, but a lot better than the pseudocode given in many classes (which is almost always wrong, too.)

In practice, the semaphores available for many systems are considerably slower than using architecture provided atomic increment operations, which means implementing a bounded buffer with two counters and two mutexes ends up being faster.

I think the UNIVAC implementation of P and V that you meant to link to is in http://www.fourmilab.ch/documents/univac/fang/hsource/schpro....

Those are the assembler macros ("procs" in UNIVAC terminology) for calling the functions previously linked.

(UNIVAC assemblers were very powerful. Arbitrary computation could be done at assembly time. If you needed some precomputed table, that was the way to do it.)

The previous link just takes me to the FANG homepage frameset, which doesn't have any functions visible on it to me. This is a common problem with linking to framesets. Or is it some kind of problem in my browser, and other people see functions in UNIVAC assembly when they follow that link?

(FWIW, I think it's fairly normal for macro assemblers to be Turing-complete, although some of them carry it off more gracefully than others.)

Right, frames. Here's the specific P and V source.

http://www.fourmilab.ch/documents/univac/fang/hsource/schedu...

Thank you!

Well, P and V are considered harmful (pun intended).

Systems using these operations are in general not "composable". In other words, it is usually not possible to compose two software systems using semaphores and/or mutexes, without rewriting these systems somehow.

Alternatives exist. For example: message passing, and STM (software transactional memory). Anybody know of other alternatives?

Message passing doesn't help either. What many programmers don't realize that synchronization problems (deadlocks) are _not_ the consequence of using mutexes or other primitives per se. They're the result of synchronization itself.

Message passing can be asynchronous, but on some level, the system might have to synchronize certain operations. If you implement a financial system, you'll certainly have to synchronize stuff even if you're using asychronous message passing to implement it -- you will simply implement synchronicity on the top of an asychronous infrastructure.

And when operations start to depend on each other, then you _have_ to think about potential deadlocks, race conditions, etc.

Basically there isn't anything that solves this for you. STM is somewhat different as the danger is not deadlocks but starvation, etc.

The way I like to put it is that using a decent concurrency mechanism like message passing or STM or even just what Go does (enforced by community standards rather than actual limitations) takes concurrent programming from an exponential-complexity problem to a polynomial-complexity problem. It's still hard, it'll never not be hard, but it doesn't have to be the insanely, mind-bendingly broken hard that it was in the 90s. The more you can avoid sharing and the more you can operate in your own little world that communicates with other worlds via immutable messages, the happier you will be, and if you occasionally have to dip a bit into true sharing, it's still easier to manage in a saner world than when you try to share everything, all the time.

There's nothing that "solves" the problem, but there are "things that will summon forth C'thulu" and "things that are merely difficult".

> Alternatives exist. For example: message passing, and STM (software transactional memory). Anybody know of other alternatives?

It should be noted that spinlocks, mutexes and conditions (and semaphores) are building blocks that are necessary to implement message passing, software transactional memory and other non-trivial parallel programming constructs. (at least until we have practical hardware transactional memory).

Spinlocks, mutexes and conditions are a "necessary evil", not "considered harmful".

If you're talking about building blocks, goto is also a necessary evil...

You will be surprised at the goto use in the linux kernel...

goto is perfectly acceptable in C code. The most common use case is for cleaning up after errors before returning, although they're also used to break out of nested loops cleanly.

goto is harmful when used improperly but fine everywhere else.

I didn't mean it's a bad thing, it was a reply to some blanket statement.

I think you missed that fpgeek was turning exDM69's comment around on itself to put goto and spinlock into the same category.

fpgeek wasn't actually making a statement about goto

Oh, nice turnaround!

That one was funnier then the orignal pun. Nicely done. :D

You can implement message passing, STM, BSP, data parallelism, etc., on top of spinlocks, or on top of other implementations of mutexes such as condition variables, or on top of semaphores; but you can also implement them on top of primitives like compare-and-swap, which is arguably even harder to use correctly.

STM and message parsing do require the low level primitives: CAS (CompareAndSet/Swap), LL/SC (Load linked/store conditional).

Morealso STM doesn't solve the transactional problem that you face with using locks (mutex). Overall STM is just a fancy thing to have but hardly solves the big problem of transaction boundaries.

Message passing is easier to reason about due to global ordering but then you need some FIFO queues that are built upon some kind of mutex or spin lock... or Lamport based one (using for single producer-> single consumer one)... or some variant of Michael & Scott queue, etc.

In the end underneath you have to do the metal, so they cannot be 'considered harmful'.

STM with database style transactions like in clojure?

http://clojure.org/refs

STM doesn't buy you much compared to locks - the transaction boundaries are the harder part (database or otherwise).

No, you can build STM on top of mutexes, too; you don't need CAS and LL/SC as low-level primitives. In fact, IIRC, Intel CPUs use a mutex in their cache coherency protocol to implement CAS and LL/SC.