During process termination, slim reader/writer locks are now also electrified


Some time ago I mentioned that during process termination, the gates are now electrified: If you attempt to enter a critical section that is owned by a thread that was terminated by an earlier phase of process termination, the entire process is forcibly terminated.

Windows Vista introduced a new lightweight synchronization pseudo-object known as the slim reader/writer lock. And if you tried to enter a slim reader/writer lock during process termination and found yourself waiting for the current owner to release it, you ended up waiting forever since the current owner was terminated by an earlier phase of process termination. The sentence "As for the home-grown stuff, well, you're on your own" applies here. Even though the slim reader/writer lock functions are exported from kernel32.dll, they don't have any special kernel powers with respect to process termination. From the standpoint of process termination, they may as well be some home-grown synchronization primitive.

In Windows 7, the kernel folks decided to bring slim reader/writer locks into the fold of objects which are electrified during process termination. Starting in Windows 7, if you attempt to acquire a slim reader/writer lock during process termination, and the lock cannot be immediately acquired, then the process is forcibly terminated.

Comments (10)
  1. pete.d says:

    Can you clarify the difference (if any) between the behavior of critical sections and slim reader/writer locks?  In particular, the conditions you wrote lead to process termination are "If you attempt to enter a critical section that is owned by a thread that was terminated by an earlier phase of process termination…" and "if you attempt to acquire a slim reader/writer lock during process termination, and the lock cannot be immediately acquired".

    Note the discrepancy between the two.  For critical sections, you only get terminated if the critical section is owned by a thread that's been terminated (very reasonable, since obviously that critical section is never going to be released).  But for slim reader/writer locks, apparently even if the lock is simply held by some other still-running thread, that's enough to get the process killed.

    Are the two criteria really different?  If so, could you please elaborate on the motivation behind having different rules for the two different kinds of locks?

    [There is no difference. There is no such thing as "some other still-running thread", since all other threads have been terminated! In both cases, the rule is "if the lock cannot be immediately acquired." I just expanded the definition of "cannot be immediately acquired" in the critical section case. -Raymond]
  2. alegr1 says:

    Is slim lock (as well as crit-sect) territory considered kernel folk turf? As far as I understand, it's pretty much usermode stuff. Also, are mutexes electrified? I guess not. But they have a separate status for such cases.

    [Right, SRW locks and critical sections are user-mode objects. I thought I explained that in the second paragraph. -Raymond]
  3. Antonio Rodríguez says:

    All of this is common sense. When you are terminating, you don't want to have a dependency on something that has already been shut down.

  4. Jonathan Allen says:

    Can I assume that this rule applies the slim reader/writer lock in .NET as well?

    [Only if .NET slim read/writer locks are the same as kernel32 slim reader/writer locks. I can't believe I had to write that. -Raymond]
  5. Jonathan Allen says:

    Well yea, that is what I'm asking. Is the .NET slim read/writer locks are the same as kernel32 slim reader/writer lock?

    [How should I know? -Raymond]
  6. Gabe says:

    It's pretty easy to just look at the source code and see that ReaderWriterLockSlim is implemented in C#. The ReaderWriterLock appears to be implemented with Windows APIs.

    [Noting of course that this discovery does not imply a contractual obligation to retain this design in future versions of .NET. -Raymond]
  7. Jonathan Allen says:

    Raymond, I was assuming that if you didn't know someone else who reads your blog would.

    [But you directed the question at me… This blog is not StackOverflow. -Raymond]
  8. Alberto Martinez says:

    Well yea, that is what I'm asking. Is the .NET slim read/writer locks

    are the same as kernel32 slim reader/writer lock?

    [How should I know? -Raymond]

    For this post your old slogan "Not a .NET blog" would be handy…

  9. Worf says:

    Actually, what happened to the slogan?

    And it is/was always "Not a .NET blog" – just said in a more microspeak/enterprisey/buzzword format…

  10. LR says:

    @Worf: If you click on any link within the "Common Tasks" box (top-right of this web page), you will still see it:

    The Old New Thing

    not actually to establish a blogging point where individuals can enrich their learns on facilitating and leveraging .NET-related activities most effectively

Comments are closed.

Skip to main content