In that case, the purpose of a lock is to prevent 2 non-simultaenous tasks from conflicting. Since the tasks are not simultaneous and memory writes are atomic, you don’t need locks here, either.
For example, you have a comm buffer where the incoming data from the modems goes to. One thread/process handling the modems/network populates the buffer and another thread/process reads from it and uses it to book seats.
The lock-free solution is to make sure the populating thread updates the index to the bottom of this buffer after writing an element (so if it gets yanked away immediately after by an OS interrupt it will be in a valid state) and the thread reading does the same thing. Each thread should use it’s own index for this, and not share with the others.
If that were true it would still be true with multiple processors, which you claimed was the only reason to use locks. But it isn’t true because the real world doesn’t work that way or even remotely close to that way.
In the real world, resources that need to be synchronized are much larger than the minimum hardware-addressable units like memory bytes or disk blocks and may need to be kept locked until some potentially lengthy processing activity completes. This is pretty basic computer science. Windows, for instance, makes extensive use of both mutexes and semaphores. So does Unix, and any other OS that supports concurrency.
This is the problem with concurrent control. It is far, far, far harder than one thinks.
Your code isn’t anywhere close to handling all the events that arise in this situation. People wanting a block of seats together or just one. Not caring about the day. Some want a particular type of seat (aisle seat on a plane, for example) but the sets of types overlap horribly. All while other people are checking on other groups of sets under other circumstances. Which could lead to seats that could be sold Right Now not being sold Right Now which is the company’s goal. There’s a many-many mapping with conditions problem here. PhD theses can be written about it.
Also note an obvious flaw in your code: The sleep timeout is something that should never be done in a case like this. Consider the cycle: Someone gets the lock first, you sleep, they unlock, someone else gets it, you wake up, still locked, go back to sleep, lather and repeat.
If you have decent locks to begin with, this is avoided. DIY hope and pray queuing is a bad idea. It goes bad far more often than you would guess. And if you have to implement your own queuing, then you are programming in the wrong decade.
At least 99% of sequential programmers are terrible concurrent programmers.
The theory is the same if it is done in software or in hardware. When Dijkstra wrote, and when I took it, the hardware pretty much didn’t support this except in the sense that you could mask interrupts in critical regions. I am involved in implementing hardware, but I’ve never had a reason to look at this particular part of it. The instruction set level is way above where I work these days.
So my question was if students just learned what OS calls or instructions to use to deal with this problem, or if they learned the reason you need special instructions.
ETA: I’m particularly interested because I used this basic principle in a system I built, though the problem was pretty far from the basic one.
In terms of air travel, before deregulation, no-shows were not nearly as common. Flying was something mostly only the rich did, the so-called ‘jet set’. Middle class people might only take a few flights in their entire lives. And since tickets were so expensive people did not change their plans and not show up for a flight so casually.
I remember being able to access SABRE thru CompuServe dialup in the later 90s. It was annoyingly slow and glitchy, nothing like Travelocity today, but you could do it…
But, if you did change your plans and not turn up in the late 60’s, you didn’t loose your whole airfare. Since the planes rane with vacent seats anyway, when you missed your booking you could still get on the next flight*.
In the Olden Dayes of the 1960s and 1970s pre-deregulation a “ticket” was an unrestricted right to fly between a city pair on a flight of the customer’s choosing. Because even fares were regulated, you could even use the ticket on a different airline than you bought it on. A separate thing called a “reservation” was a soft commitment by the customer to show up on a particular day for a particular flight. You could have a ticket and no reservation, or a reservation and no ticket.
The situation was much more like a reservation at a restaurant is today than like a baseball game is today. IOW, no binding commitment by the customer at all.
No-showing for a flight carried exactly zero penalty to the customer. Changing plans at the last minute carried exactly zero penalty to the customer. Cancelling a ticket carried exactly zero penalty for the customer.
It didn’t take long as society became more consumerist and air travel got cheaper before some customers noticed an opportunity to game the system with one ticket and multiple reservations for their convenience. “Why not? It’s free so it must be OK” they rationalized. Soon the airlines were inundated with “full” flights that left 2/3rds full day after day.
The airlines counter-attacked with overbooking. The consumers, via the government, counter-counter-attacked with denied boarding compensation laws. The airlines counter-counter-attacked with yield management, change fees, non-refundable tickets, different fare levels, and all the rest.
And now we’re locked in this MAR doctrine (Mutually Assured Rip-off). How we climb down from here is about as easy to figure out as how countries can climb down from the nuclear MAD doctrine.
In my experience business people did this a lot, since if they were uncertain when their meetings would end they could book several flights and be sure they would be on the earliest they could make. As you said, there was no penalty for no-shows or ticket exchanges. It took a while for the exchange penalty to start - in the early 1980s when I flew a lot for work I’d often change tickets if I got there early, though I never multiple-booked.
However I disagree with** Hail Ants** about air travel being mostly for the elite. Maybe in the 1950s, and early 1960s, but by the early 1970s when I was in college I flew all the time and it was no big deal. They had student discounts, and my flight from Boston to New York was under $30. Not much more than than the bus. As a grad student in 1976 I flew on my own dime to a conference in Boulder, and it wasn’t a big hit to my budget. It is relatively cheaper now, but it wasn’t expensive enough back then to be out of the range of the masses.
And you got fed also.
It depends on the railway company in question. Deutsche Bahn does not require mandatory seat reservations for its trains, not even the ICE high-speed network (although you can, at an additional fee, opt to book a seat); it is quite common even today to have an overcrowded train with people sitting on the floor. In some other countries, trains, or at least the high-speed ones, operate on a basis that more closely resembles airlines, with mandatory seat reservations.
Wow, that’s awesome info. Not old enough to remember this, nor had I ever met anyone who flew back then. I have heard guys say that, “Back then even in coach, you didn’t board an airline without a jacket & tie!”