Originally posted by indepe
View Post
Its really simple when you are not attempting atomic and you just use old syscall form of lock for this when the function is wake up as many as you can waiting in the kernel que for the lock and telling them that the event was triggered and setting the state back to nothing if it set or leaves it alone if it not set. This is not using atomic shared memory its using per process memory remember we are talking old school locking before atomic memory operations in this design. So its not needing to call a lower level function like set-event in a pulseevent in windows because its not in fact atomic. Pulseevent just has to find the process that should be started set the that they have the lock in their process memory and pass them to the scheduler. Per process state of lock is something your atomic locks was not designed to-do same with the idea that multi items take the same lock at the same time.
There are old class of lock used for process management/thread queing not data protection these are not atomic class locks guess what Windows Event is. Windows Event is a horrible hybrid some of it use cases is a 1 to 1 active thread lock like a normal atomic others use cases of Windows Event is a 1 lock to many active thread lock at the same time that is absolutely not atomic. This beast Windows Event is not atomic lock but its still a lock.
Since this stuff is pre atomic locking it doing operations that atomic locks should not do in ways you would not with atomic locks without a lot of work. Like you are not going to duplicate that you have the lock/event in per process memory with atomic because that undermines total userspace solving of locking but pre atomic where you have the kernel setting the lock state in the per process memory and the lack of atomic memory protection and the poor early MMU/embedded MMU you will do this(yes there are MMU without page tables so you cannot share memory safely between process in the pre atomic world so memory duplication is a thing). Once you have per process lock state of the pre atomic locks you can now perform horrible actions that don't suit atomic locking at all.
The idea that pulseevent had to call a set-event outside it self is because you are thinking this has to fit into atomic style of lock but event is a pre atomic lock with per process lock state in the process memory not shared and the kernel can keep track of how many of those it started.
Fun right pre atomic locks have the concept of selective signalling and this is easy todo when the lock state is unique per process and is insanely hard with atomic lock where the lock state is in shared memory between processes.
Windows Event is a feature rich pre atomic style lock these are design that the lock will be kernel managed and its not in fact using shared memory between processes for lock state and due to this it can do stack of horrible things like permission guided locking and multi threads holding the same lock at the same time.... Basically stack of world breaking things to atomic lock concepts due to being world breaking to atomic lock concepts comes really hard to emulate with atomic locking and next to impossible to-do in a performance way using atomic locks.
This is purely a different class of locking. Problem here you are keeping on thinking everything has to be atomic when the lock you are looking at is a feature rich pre atomic style of lock is its really not atomic but in limited use cases of it can look atomic. Other problem is courses teaching locking don't cover these pre atomic locks.
indepe really with atomic you are being like a person with a hammer so everything looks like a nail including screws because they don't know screws exist.
Comment