tag:blogger.com,1999:blog-5246987755651065286.post3850675119549852720..comments2024-02-22T16:15:42.388-08:00Comments on cbloom rants: 07-26-11 - Implementing Event WFMOcbloomhttp://www.blogger.com/profile/10714564834899413045noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-5246987755651065286.post-33022597733007447392013-01-27T10:53:24.690-08:002013-01-27T10:53:24.690-08:00@mqudsi - I just had a quick look at it, so I coul...@mqudsi - I just had a quick look at it, so I could be wrong, but in fact it seems the 'pevents' is exactly the kind of bad polling implementation that I'm talking about.<br /><br />If you do a WFMO on 4 events with pevents, you won't go to sleep once and then wake up once when all 4 events are set. Instead you may go to sleep and wake up over and over and each event is set. <br /><br />In fact pevents seems to implement WFMO by waiting on each event one by one in order.<br />cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-88908371233520780232013-01-23T19:57:25.860-08:002013-01-23T19:57:25.860-08:00There is an open source library called pevents (MI...There is an open source library called <a href="https://github.com/NeoSmart/PEvents" rel="nofollow">pevents</a> (MIT licensed) that implements Win32 events for *nix on top of pthread objects. It includes WaitForMultipleObjects (WFMO) support, and it doesn't exactly poll.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-71121371954303536992011-09-17T17:44:45.050-07:002011-09-17T17:44:45.050-07:00I think that polling internally from the kernel is...I think that polling internally from the kernel is like orders of magnitude better than doing so in a user-space implementation. It also really isn't what I mean by "polling" , in the sense that it isn't actually waking up the thread in question to make it check its own state.<br /><br />When you poll in the kernel, it's at a point where the kernel is considering waking up a thread; it checks various states and decides not to wake that thread. It then moves on and runs some other thread.<br /><br />The implementations of polling in user-space generally involve completely waking up the thread in question, it then checks whether it should be awake, decides it shouldn't and goes to sleep. So you've run the kernel scheduler twice (once to wake the wfmo thread and once to wake the next thread) and you've done a full extra thread switch.<br /><br />Plus the cost of all the calls to check the state of the events isn't a user-kernel transition if you do the polling in the kernel, etc. etc.<br /><br />Basically what's good practice inside the kernel vs. in user space is very different.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-55432006952530210512011-09-17T12:51:48.733-07:002011-09-17T12:51:48.733-07:00I hate to break it to you: the Windows Kernel WFMO...I hate to break it to you: the Windows Kernel WFMO(WaitAll) mechanism actually more or less does the polling thing internally, at least on win7 and above.<br /><br />It turns out that doing WaitAll any other way is difficult to make scalable. WaitAll is rarely enough used, that the inefficiency was viewed to be acceptable.Unknownhttps://www.blogger.com/profile/01547571644651252736noreply@blogger.com