Originally posted by Weasel
View Post
Notice here wait for multiple is not Mutex but instead event. Happens that the event in windows is not atomic design.
The give away is right on this page. EVENT_MODIFY_STATE is the give away. The fact state is meant to be able to change while running.
Do notice on this page that Mutex there is a space left in the API/ABI for a Mutex to be a muggable lock like a EVENT is with the but that does not mean its not muggable.
There is also another bit of fun on the security page.
SYNCHRONIZE (0x00100000L) The right to use the object for synchronization. This enables a thread to wait until the object is in the signaled state.
Your general atomic locking is not your old school privilege/kernel controlled/pre atomic locking. The big things here is the old pre atomic locking include methods to take back the lock by force that requires extra information on who has the lock to be tracked by privilege party being the kernel. Yes I know its a idea to say we will avoid syscalls to take out a lock but these old pre atomic are designed to use syscalls and the difference in privilege between kernel and user-mode and have security privileges on the locking to be processed as part of the locking solution. These beasts are different.
Yes saying this stuff can be implemented with atomic locking in userspace means you don't understand the problem at all. These are locking structures with privileges designed to be kernel processed that were not designed to use atomic to avoid syscalls. Attempting to avoid syscall makes implementing them hell.
Comment