Comment by CyberDildonics
15 hours ago
It absolutely can make a difference because if you have locks that are supposed to sync or wake up other processes you care about latency not cpu usage.
15 hours ago
It absolutely can make a difference because if you have locks that are supposed to sync or wake up other processes you care about latency not cpu usage.
What specifically are you saying can make a difference?
I'm saying that extra overhead from making your lock work across processes should be very tiny. That overhead shouldn't add much more than a microsecond in either latency or CPU usage, compared to an in-process lock.
You were saying "reasonable overhead" makes no difference because something "isn't called much". This is not only ambiguous but also not true because latency is important.
What calls specifically are you talking about between windows and linux? This was started by someone talking about WaitForMultipleObjects.
I wasn't excusing all overhead, I was excusing the difference in overhead caused by making the lock more flexible. Because that's what the discussion is about, a lock that can be shared between processes versus a lock that can't be. The penalty for being "too flexible".
But assuming reasonable implementations, the difference between those two lock styles shouldn't be more than about a microsecond, should it? So that's fine for a lock that's only used 100 times a second.
I'm not comparing windows and linux anywhere.
1 reply →