It's just a lock. It's analogous to a pthread_mutex_t (which on Linux is a futex), where the operation in the uncontended case is a single atomic access to shared memory. The contended case needs to enter the kernel to suspend, or to make a decision about who to wake up, and that seems to be the subject of the blog post.
In embedded (not sure how applicable here?) you invoke a critical section to access a lock. You will have an interrupt handler. Inside that, you will invoke a critical section, which prevents other processes from interrupting it. Inside the CS, you an get a handle to a mutex that has shared state. The mutex is what I would call the "lock" in this convention.
To add to what others have said, additional characteristics of a Win32 critical section:
- It is purely an in-process lock, and originally the main way of arbitrating access to shared memory within a process.
- It is counted and can be recursively locked.
- It defaults to simple blocking, but can also be configured to do some amount of spin-waiting before blocking.
- CritSecs are registered in a global debug list that can be accessed by debuggers. WinDbg's !locks command can display all locked critical sections in a process and which threads have locked them.
Originally in Win32, there were only two types of lock, the critical section for in-process locking, and the mutex for cross-process or named locks. Vista added the slim reader/writer lock, which is a much lighter weight, pointer-sized lock that uses the more modern wait-on-address approach to locking.
A critical section is code that accesses mutable shared data in a non-atomic way (i.e. as several steps, the classic example is: fetch data into a register, process that data, store the result back into memory). A lock is a mechanism that protects such data by preventing other code (or other threads running the same code) from accessing that data until the critical section completes.
Locks come in several types. A developer picks one type depending on the use of the protected data; for example, exclusive, reader-writer, and others.
Locks are great at preventing data corruption and data loss, but come with issues. They can hurt performance, can cause "liveness" and other issues, and are usually "advisory" ("mandatory" locks which are enforced by the OS are rarely available) so developers must remember to protect data by using locks around every critical section.
Modern hardware includes support for many lock-free mechanisms that can greatly reduce the need for locks.
This is hands down the worst Old New Thing he ever wrote. He either is, or at least should be, ashamed of the poor engineering his colleagues are doing, and trying weakly to defend them.
Monkeying with critical sections is hard. Monkeying with them due to performance and memory optimization while maintaining correctness is incredibly hard. If they'd done a good job of it, no one would have noticed, and Raymond would have had a cool story to tell. Instead we got this.
This shows that having a legal way to run outdated operating systems is always important to guarantee that old software runs exactly as intended. Online activation schemes make this problematic.
The solution seems to be installing and fully activating the operating system in the VM while it's still possible, then archiving the VM image. However, I don't know how reliable this method is, since the Windows OS may require reactivation if the hardware configuration changes significantly. Therefore, if the future VM host machine exposes slightly different hardware to the guest machine, the activation might be gone.
Criticisms of his post aside.
Isn't it unfortunate, the absolute degree everything legacy is at least in some way tethered to windows. If only there had been an open alternative, it would allow huge communities to emerge keeping very old software/games working indefinitely. Not that linux was even remotely close to being usable even only twenty years ago. Relying on a giants benevolence is never going to work in the long run. Their contemporary direction is only a function of what side of the bed theyd like to turn on today.
14 comments
[ 2.6 ms ] story [ 36.0 ms ] threadToday you can use SRWLock or WaitOnAddress on Windows(or std::shared_mutex for portable impl, but not std::mutex because reasons).
- It is purely an in-process lock, and originally the main way of arbitrating access to shared memory within a process.
- It is counted and can be recursively locked.
- It defaults to simple blocking, but can also be configured to do some amount of spin-waiting before blocking.
- CritSecs are registered in a global debug list that can be accessed by debuggers. WinDbg's !locks command can display all locked critical sections in a process and which threads have locked them.
Originally in Win32, there were only two types of lock, the critical section for in-process locking, and the mutex for cross-process or named locks. Vista added the slim reader/writer lock, which is a much lighter weight, pointer-sized lock that uses the more modern wait-on-address approach to locking.
Locks come in several types. A developer picks one type depending on the use of the protected data; for example, exclusive, reader-writer, and others.
Locks are great at preventing data corruption and data loss, but come with issues. They can hurt performance, can cause "liveness" and other issues, and are usually "advisory" ("mandatory" locks which are enforced by the OS are rarely available) so developers must remember to protect data by using locks around every critical section.
Modern hardware includes support for many lock-free mechanisms that can greatly reduce the need for locks.
Monkeying with critical sections is hard. Monkeying with them due to performance and memory optimization while maintaining correctness is incredibly hard. If they'd done a good job of it, no one would have noticed, and Raymond would have had a cool story to tell. Instead we got this.
Sigh, Microsoft, what's happening over there?
https://news.ycombinator.com/item?id=43772311
The solution seems to be installing and fully activating the operating system in the VM while it's still possible, then archiving the VM image. However, I don't know how reliable this method is, since the Windows OS may require reactivation if the hardware configuration changes significantly. Therefore, if the future VM host machine exposes slightly different hardware to the guest machine, the activation might be gone.