Chances are good you’ve never heard the term “semaphore” before.
(Unless, of course, you’re a train enthusiast or a programmer. In the latter case, you really should know what a semaphore is and how to use it properly!)
But the fact that you don’t know the term doesn’t mean you’re not aware of the concept.
Actually, I’d bet that you’re using semaphores quite frequently. You’re at times very grateful for their existence, e.g. each time you use a public bathroom. And if you’ve ever been travelling by train, they might have saved your life on occasion.
You think that software, trains and public bathrooms is a weird combo? Well, read on. You might be in for a few aha moments…
So what IS a semaphore…
The word “semaphore” originates in ancient Greek: “sema” means “sign” or “signal”, and “phoros” is a “bearer”.
I.e. a semaphore is nothing but a bearer of signals – a signalling device.
But alas, that translation doesn’t really capture the essence of what a semaphore is.
Way back, when people built the first railway lines, they realized that things could get ugly pretty quickly if two trains were using the same track at the same time.
So they needed a way to signal, among other things, whether a certain track was “occupied” or “availabe”.
In order to achieve that, they transferred similar solutions (and the name “semaphore”) from nautical shipping, and adapted them to the needs and technical possibilities of railway lines: Early railway semaphores used to be poles with an arm, and the angle of said arm could be changed.
With such a semaphore, for example a horizontal arm would (metaphorically speaking) block the track, and thus was a stop signal. An arm at some other angle gave a train the all clear to drive on.
Nowadays, railway semaphores a bit more complex, digitalized and all that, but the concept behind them is still the same:
Essentially, you can use a semaphore to signal whether a resource (= a railway track) is free to use or not.
(If that does remind you of public bathrooms, btw, then you’re spot on. I’m fairly sure you’ve occasionally been grateful for the fact that you can lock the door of a public bathroom behind you – and thus mark that this resource is in use…)
… and what does that have to do with database programming?
So even though semaphores developed technically over time, the concept behind them continues to play a key role in railway traffic safety.
But then, quite a few decades later, along came computers. And with them code, and programmers.
Like the railway engineers, the programmers realized pretty quickly that things can get really ugly if two pieces of software try to use the same resource at the same time:
Important data could be overwritten when two programs access a database entry at the same time. An autonomous vehicle could get conflicting commands and thus drive in the wrong direction and kill people. Well, you get the gist.
So, the programmers being smart people (and some of them being pretty nerdy, too, and thus knowing a lot about railway systems), they figured that they needed the exact same concept which has saved railway traffic from disasters: They needed to be able to mark resources as “occupied” or as “available”.
In short, they needed semaphores.
(They even stole the name, btw. 😉 )
But how are semaphores used in programming? I mean, you can hardly put up a pole with a physical arm somewhere in your code, right?
Well, the concept behind it really IS the same:
You’ve got a finite resource. And everybody (= every piece of code) who wants to use this resource first has to lock it – and then unlock it after usage.
While railway tracks are (to the best of my knowledge) only ever used by one train at a time, computer resources can exist in multiples.
Say you’ve got a sweet new gaming PC with eight CPU cores. Then the first process which needs computing power locks one of the eight cores. The second process might lock two cores at once, since there are enough avaible. In the meantime, the first process finishes and unlocks the core it had used, thus making it available to other processes again. Etc.
(Yep, I know this explanation is a bit simplistic – but remember this article is about the semaphore concept, not about the intricate details of modern multithreading and whatnot CPUs.)
The semaphore concept in a nutshell
The concept really is that simple:
Properly lock them when you’re going to use them.
And properly unlock them when you’re done.
Now, you might have noticed my unobtrusive use of the word “properly”… 😉
Locking the door of the public bathroom behind you is usually pretty straightforward. And unlocking it when you’re done is kinda self-evident.
But as any programmer can confirm, the locking and unlocking of resources in complex settings isn’t always without difficulty…
(Btw, if at this point you’re thinking “Great, I know how to lock bathroom doors. So why am I even reading this article at all?”, you should definitely read on!
Semaphores have a lot of applications in everybody’s life. And it doesn’t hurt to learn from other people’s mistakes, right?)
What if things don’t work as they should?
So what can go wrong when you use semaphores?
Somebody forgets to lock a resource.
The most obvious case – and I hope I’ve been able to make it very clear that this can have very severe consequences. ’nuff said.
Somebody forgets to unlock a resource.
This can be a real dealbreaker.
If a resource is never unlocked anymore, it’s gone for all practical purposes.
Like when you’re in a long queue in a public bathroom, and some stalls are simply locked and thus unusable for no obvious reasons.
(Yeah, I’m sure they’re doing renovations in there and all that. This is just an example of how that situation can suck, ok?)
Somebody locks a resource they don’t need.
In the long run, there isn’t much harm done (provided they unlock that resource again in a timely manner, see above).
But still, it’s a restriction – you’ve got resources blocked for no reason. And depending what your task is, this can slow you down considerably or even make things unworkable in pratical terms.
Somebody unlocks a resource they had never locked.
On first glance, this might seem trivial – but in reality it can be a life-or-death problem.
If a train would accidentally unlock the semaphore of a track which it isn’t using, the train which had locked said track in the first place would still be on it, with potentially lethal consequences.
Or you’re in a public bathroom where anybody can “unlock” bathroom doors – even if they’re themselves not using a stall, but waiting outside.
Imagine how much fun that would be…
Resources mutually lock themselves and can’t get unlocked anymore.
This can happen when different resources are managed by different semaphores, and there are complex rules about who can lock and unlock a resource under which circumstances.
In the worst case, you can end up with a situation where nobody can act anymore, because everybody is waiting for somebody else to unlock a necessary resource first.
This can lead to total standstill – not a nice thing to have either.
(If you want to dive more deeply into this particular problem, read up on the “Dining Philosophers Problem”.
There are no clear rules about priorities – who has first dibs on a resource, and under which circumstances?
Again, the challenge here is pretty obvious in practical terms:
A “first come, first serve” basis might work fine in some settings. In other settings, it’s really important to prioritize resources and allocate them primarily to more urgent or more important processes.
And how does all of that matter to you?
So… We’ve talked a lot about railway tracks and public loos, but that still leaves one important question…
… how does all that matter to you?
I wrote at the beginning that the pure translation of semaphore as “signal bearer” isn’t really meaningful. The interesting part is what it signals and under which circumstances.
Namely, available and occupied resources, in the context of intelligent sharing, managing and allocating of resources.
And ain’t that a topic which is more relevant than ever in our world?
In practical terms, some applications for semaphores are obvious (bathroom locks).
But there are a ton of other applications in business and private life that you might not have thought about yet – and a lot of chances to learn from the most common mistakes in semaphore usage.
… in business
In groups or large organisations, sharing resources saves money. So far, so easy.
The really tricky part is to find a reliable system that commits people to properly locking and unlocking resources. Otherwise, see above, all sorts of undesired things can happen.
Thus if you’re responsible for any resources for a larger group of people, or if you’re managing any kind of project at all, resource management (allocation and de-allocation) is a powerful consideration.
And even if you’ve got no resource responsibility at the current time, think about this article the next time you can’t print your urgent report because the colleague from three rooms over is blocking the printer again.
Treat it like the semaphore problem it is, and talk to people from this point of view. You might be surprised about the results!
And btw… Transferring the idea of semaphores onto other, hitherto unconnected areas, can also bring you new business ideas:
Wherever resources can be shared, there is room for somebody to manage the sharing – car sharing being an obvious example.
… in your private life
In your private life, some issues might come up again and again, and maybe looking at them from a semaphore point of view can make a difference to your happiness.
If there are arguments in your family each morning about who gets to use the bathroom when, and for how long, then that’s not mainly a problem of your teenage kids being unreasonable (although that might be the case, too 😉 ) – it’s a problem of resource management:
It’s about allocating and de-allocating the bathroom according to smart rules.
And about making sure everybody follows the agreed-upon locking and unlocking procedures.
(That last part sounds a wee bit too technical for you? Think about it like this: When you brush your teeth, you’re probably perfectly cool with your partner coming in and combing his/her hair. No need to lock in this case.
But when your teenage son finally leaves the bathroom after his 30-minute grooming-and-showering session, it would be really great if he’d not just quietly unlock the door, but actually tell the rest of the family that the bathroom is now available. The proper “unlocking” in this case is not the actual unlocking, but letting everybody else know he’s done.)
So instead of everybody being stressed out each morning, make all family members sit down and discuss this as a semaphore problem:
There’s a resource (your bathroom). Who gets to lock it for which purose when, and for how long? Who gets priority under which circumstances? How will you signal clearly that the door is not locked anymore, and the room is free to use?
Instead of arguing about personal character traits of each family member, this might be a refreshing exercise… 🙂
P.S.: For full disclosure (and to satisfy the more nitpicking types among us), I should probably add that a semaphore in nautical shipping is more than just a lock/unlock switch – in the nautical use of the term, semaphores can convey a lot more meaning through more detailed positions, e.g. an alphabet by flags.
Also, railway semaphores aren’t always just a lock/unlock either. They, too, can have various arm positions (or in the digitial versions nowadays, various combinations of lights switched on or off), and thus convey more detailed meanings to a train driver.
I’ve decided to ignore this slightly different concept for the present article, because a. the lock/unlock concept I’ve illustrated here with all its potential problems and pitfalls is valid and useful in itself, and b. honestly, ain’t this text long enough already? 😉
But if you’re really interested in how semaphores can be used to transfer more complex meanings, I might be convinced to look into that in another article – shoot me a comment below, ok?
Image: Sascha Brück via Wikimedia Commons under the Creative Commons License Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0).