Hacker News Reader

Comment by jojomodding | Hacker News Reader

How is a critical section different from a lock?

They gave the different sorts of locks different names. Locks usable across processes are mutexes, and locks only usable within a process are critical sections.

Different names can be a huge source of confusion. The C++ standard library uses `std::mutex` as a lightweight synchronization lock. But on Win32, `Mutex` refers to a heavy kind of lock that can be used across processes. Very different things despite both using the same word "mutex" in the name.

Here's another example of confusing terminology. In the C standard library, `fflush` just advances you to the next step, where your buffer goes out to the 'write file' system call, where your data sits in the disk cache to be written later on. Meanwhile, Win32's `FlushFileBuffers` actually forces everything out to the disk, acting much more like `fsync`. Yet again, very different things despite using the same word "flush" in the name.

Really, the oddity is that Microsoft thinks there's a significant difference between in-process communication and cross-process communication. They're all running on the same physical memory and the kernel can share access to that.

I mean you can put a critical section inside of shared memory, but the heavy mutex is used for situations where you need to actually name the mutex, then have another process open it by name. Example uses include preventing multiple instances of a single program from running. Not the kind of thing you'd use a std::mutex or critical section for.

note: Do not actually put a critical section inside of shared memory. They allocate semaphores specific to one process.

On Windows they are significantly different; it's not just a matter of sharing a page of memory (though you certainly can do that if you want), because on Windows basically every kernel-provided cross-process object must be a fully securable kernel object that you can attach ACLs to, and the kernel has to be in the middle of operations to enforce those access controls (in order to conform to the old DoD TCSEC orange book requirements for mandatory access security).

The Mutex thing kind of makes sense. std::mutex came in at C++11, while Microsoft's CreateMutex call goes back to at least Windows 95. "Mutex" just means "a particular type of lock", it doesn't say anything about the implementation, nor about the performance. It'd be dangerous to assume the performance characteristics of C++'s std::mutex and Rust's std::sync::mutex are anything alike either.

fflush and FlushFileBuffers both just happen to have "flush" in the name. The fact someone decided that fflush doesn't actually flush the file buffer and added fsync to actually flush the buffers, does make for a very frustrating experience, but I find most of the POSIX API to be like that. See also: sync(void) vs fsync(int fd) vs syncfs(int fd).

fflush does flush the userspace buffer, if it should affect the kernel, it needs to be the syscall, which is called fsync.

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.

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.

It's a kind of lock. Critsecs are faster and lighter weight than mutices (kinda like a futex), but cannot be shared between processes, only threads within a process. Mutices can be shared between processes but because of that they have to make syscalls every time they're locked or released.

Mutex isn't latin. The plural of mutex is mutexes.

It’s a running joke in the field to have exotic pluralizations. Mutex->mutices is one, box->boxen (by analogy to oxen) is also pretty common.

We need more casual light-heartedness in this line of work considering how much casual bullshit there is.

> box->boxen (by analogy to oxen) is also pretty common.

Not to mention (from way back when) VAX -> VAXen.

> there's two hard problems in computer science: we only have one joke and it's not funny.

https://news.ycombinator.com/item?id=42046226

Except it actually is Latin. Both "mutual" and "exclusive" are borrowings from Latin.

No, it's an English word. The fact it's related, distantly, to some words in Latin doesn't mean mutex is Latin.

I'm pretty sure you could construct it in many other modern languages that have some Latin influence as well… So why do you think "index" is a Latin word and "mutex" isn't then?

I don't think "index" is a Latin word? You're probably asking the wrong person, I am quite comfortable to say indexes, and indeed sheeps -- it's an English word I can just put the -S noise at the end to pluralize it and that'll be fine even if (as with ox) there is a special case rule that some people insist matters for this word or that one.

Likewise I'm comfortable with "Can't nobody prove nothing", which I think is a succinct way to express an opinion that would be rather awkward when expressed in the prestige dialects of English instead.

plural of mutex is indeed exmut (exclusive mutation) :)

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.

Critical sections are very old, and bloated version of a mutex, but there isn't a good reason to use them today.

Today you can use SRWLock or WaitOnAddress on Windows(or std::shared_mutex for portable impl, but not std::mutex because reasons).

Reply on news.ycombinator.com