Concurrency - An aside

Sorry, I've got a massive headache today, and really don't feel up to writing the next item in the concurrency series, I should have something for Thursday (tomorrow's a day off for me :)).  Meanwhile, I wrote this up a bit earlier during the series:

My discussion about critical sections the other day got me to thinking about OS/2.  One of the books on my bookshelf that I don't read that often is Gordon Letwin's "Inside OS/2".  At the time, it was groundbreaking - an OS design manual from the designer of the operating system.  In many ways, it was the inspiration for Helen Custer's Inside Windows NT.

At some point I'll write about Gordon's book, it's actually a fascinating look at what Microsoft considered the state of the art in operating system development back in the late 1980's.

But one of the things I found (with 17 years of hindsight) was the OS/2 notion of "critical sections" as referenced by the DosCritSecEnter and DosCritSecLeave API.  Unlike the Win32 concept of critical sections (where a critical section prevents more than one thread from calling EnterCriticalSection on a particular critical section), the OS/2 concept of critical sections was radically different.

According to "Inside OS/2", when you entered a critical section, all the other threads in your process were suspended.  That's right - in OS/2, concurrent access to data structures was enforced by preventing any other threads in your app from being scheduled.

Now, in reality, this isn't really what happened - instead you'd use the critical section to protect another data structure that would in turn control access to the resource.  In effect, the OS/2 critical section is the user-mode equivalent of an NT spin lock on a uniprocessor machine.

But I sometimes find it fascinating that the OS/2 designers implemented these as their first class synchronization structures.