Why is the !locks command called !locks even though it debugs only critical sections?

Commenter DWalker07 notes that the !locks command is called !locks even though it doesn't actually debug all types of locks, only critical sections. Why the bad name?

Because at the time it was written, critical sections were the only types of user-mode locks.

In the original incarnation of Win32, there were semaphores and mutexes and other kernel-mode synchronization objects, but the only user-mode synchronization objects were critical sections. Seeing as they were the only type of synchronization objects available in user mode, they were informally referred to as "locks" because when you have only one kind of thing, you don't really worry too much about being specific.

If there's only kind of wristwatch, then you don't really bother being specific about the fact that it's a spring-wound analog-readout time-only watch. You just call it a watch. Of course, later, when battery-powered digital-readout smart watches become commonplace, your old documents that talk about "watches" may seem confusing. "Why do these instructions for troubleshooting watches not work for my battery-powered digital-readout smart watch?"

Indeed, for a very long time, critical sections were the only user-mode synchronization objects that came with Win32. It wasn't until Windows Vista that a whole bunch of new user-mode synchronization objects became available, things like slim reader-writer locks, condition variables, and one-time initialization. Until then, the word "lock" was sufficient.

Comments (10)
  1. Damien says:

    Post seems rather incomplete – are you waiting for a lock before finishing it?

    1. Antonio Rodríguez says:

      Hope it’s not a deadlock – because I want a new article tomorrow :-) .

    2. Scarlet Manuka says:

      What additional information were you looking for? The subject of the post is “why is the !locks command called !locks even though it only does critical sections?” and the answer is “they were the only type of user-mode locks around when it was named.” There’s a bit of discussion to flesh it out, and some supplemental information; there doesn’t seem to be anything more to add.

      1. Damien says:

        When I first read the article, it stopped with Until then, the word “lock”. More words appeared later.

  2. DWalker07 says:

    That sounds reasonable. We just need a time machine to fix things.

  3. Andrew says:

    Retronym needed.

  4. Medinoc says:

    Which reminds me, do “fat” reader-writer locks exist? Stuff that can have one writer at a time, but uses regular kernel object handles that can be waited on with WaitForMultipleObjects? I searched a bit, but haven’t found any…

    1. Jan Ringoš says:

      LockFileEx? But you need to use LockFileEx again to wait, not WaitForMultipleObjects, and also no timeout, and who knows if CancelIoEx will work.

    2. Sergei Vorobiev says:

      Even if there were, WaitForSingleObject() won’t cut it since there is no exclusive/shared semantics.

      Consider creating a bunch of mutexes. Reader acquires one mutex according to some hash of current cpu, tid, whatever. Writer acquires all in some well-defined order.

    3. Joshua says:

      You could carry out the sequence to construct Reader-Writer from semaphore, use the kernel Semaphore, then unwrap the logic so you can use WaitForMultipleObjects.

Comments are closed.

Skip to main content