通过

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.

Comments

  • Anonymous
    February 22, 2005
    The comment has been removed
  • Anonymous
    February 22, 2005
    Did OS/2 ever run on multi-CPU machines? I mean, on a single-CPU it's probably not a bad construct and you could write some pretty efficient locking constructs on top of it. But on a single-CPU, preventing other threads in your process from being scheduled is not a huge deal (assuming you didn't do it for very long).

    On a multi-CPU machine, it's a totally different matter though, because another thread of your process could /already/ be running when you "entered" the critical section, which'd mean you'd have to suspend that thread and essentially "force" a context switch on the other CPU...
  • Anonymous
    February 22, 2005
    Dean, as far as I know, it was only for single core machines.
  • Anonymous
    February 22, 2005
    Don't forget about "Mutants", Dave Cutler's name for NT's implementation of OS/2-compatible mutexes.
  • Anonymous
    February 22, 2005
    IBM had a version of Warp Server that was SMP-enabled.
  • Anonymous
    February 22, 2005
    > 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.

    Which was vastly different from what the rest of the industry considered the state of the art in operating system development back in the 1980's ... or 1960's, when critical sections were known, IBM mainframes had threads though their APIs weren't really orthoganal enough, and aircraft had real-time multitasking systems. Sorry to see your massive headache though.
  • Anonymous
    February 22, 2005
    Norman, yup, that's why I called it out as state of the art at Microsoft.

    Things changed rather drastically when Dave Cutler joined the company.
  • Anonymous
    February 22, 2005
    I think it's all about terms we use. We may use same words but think about different things. I remember when I first saw KeEnterCriticalRegion/KeLeaveCriticalRegion routines I thought it was some like EnterCriticalSection/LeaveCriticalSection in user-mode. But as it turned out, it was about completely different concept.
  • Anonymous
    February 22, 2005
    Bah, the VMS Internals book predates Inside OS/2.

    Now VMS Internals was an OS bible to end all OS bibles.
  • Anonymous
    February 22, 2005
    I think I threw my copy out recently part of batch of books that had gotten moldy due to being stored in damp conditions.
  • Anonymous
    February 22, 2005
    I was never able to find a copy of Letwin's book, as it had gone out of print by the time I realized I needed it (sorry, Peter, I prefer non-moldy reference books!). Consequently, I never appreciated the differences between OS/2's and NT's implementations of critical sections.

    Do you suppose this was caused by OS/2's 80286 origins?

    Chip H.
  • Anonymous
    February 23, 2005
    > Things changed rather drastically when Dave Cutler joined the company.

    At both MS and DEC.

    :-(
    ScottR, who loved working at DEC.
  • Anonymous
    February 23, 2005
    > that's why I called it out as state of the
    > art at Microsoft.

    Ooooh, sorry, I didn't recognize a fellow cynic when staring me in the face. Thank you.

    > Now VMS Internals was an OS bible to end all
    > OS bibles.

    I thought MULTICS put a stop to that?

    By the way one famous programmer has said that those who don't understand Unix are doomed to reinvent it -- poorly. I thought that should have been said about MULTICS, especially in view of the way Unix lovers (along with others) reinvent MULTICS poorly.