Hacker News Reader

Comment by Dwedit | Hacker News Reader

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.

View on HN

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.

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).

Reply on news.ycombinator.com