5 ms·

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.

Dwedit 1y ago
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.
- o11c 1y ago
  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.
  - Dwedit 1y ago
    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.
    - Dwedit 1y ago
      note: Do not actually put a critical section inside of shared memory. They allocate semaphores specific to one process.
  - drysart 1y ago
    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).
- jeroenhd 1y ago
  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).
  - 1718627440 1y ago
    fflush does flush the userspace buffer, if it should affect the kernel, it needs to be the syscall, which is called fsync.

Dwedit 1y ago

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.

o11c 1y ago
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.
- Dwedit 1y ago
  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.
  - Dwedit 1y ago
    note: Do not actually put a critical section inside of shared memory. They allocate semaphores specific to one process.
- drysart 1y ago
  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).
jeroenhd 1y ago
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).
- 1718627440 1y ago
  fflush does flush the userspace buffer, if it should affect the kernel, it needs to be the syscall, which is called fsync.