Problem with XP scheduler?
in [Win32 Kernel]
|
From: Paul Baker [MVP, Windows Desktop Experience] on 15 Jan 2010 12:55 m, "m" <m(a)b.c> wrote in message news:uuFwl7XlKHA.1824(a)TK2MSFTNGP04.phx.gbl... [snip] > to effectively use SendMessage one must know the following: > > 1) The thread that handles the target window (either this thread or any > other in the system) > 2) That any remote thread handler does not call SendMessage or use any > other sync objects that might be owned by the calling thread since > deadlocks will occur. I left #2 off my earlier list that I mostly lifted from documentation :) #2 has bitten me a couple of times in the past. Not because I didn't know it to be true, but partly because it was not forefront in my mind when I was adding the synchronization objects and partly because it can be complicated to assess whether existing code is affected. (My real problem is that I am mixing complex multi-threaded and distributed processing with a UI that needs to be synchronized with it, which is where most of the SendMessage's come in. I am working on splitting it into a server with no UI and a client with UI). Paul
From: m on 15 Jan 2010 20:43 okay - you have me one that one ;) The Win16 implementation is radically different from the Win32 /64 one, but the same semantics, and potential deadlocks, exist on both "Alexander Grigoriev" <alegr(a)earthlink.net> wrote in message news:O3LNQZZlKHA.5304(a)TK2MSFTNGP06.phx.gbl... > > "m" <m(a)b.c> wrote in message news:uuFwl7XlKHA.1824(a)TK2MSFTNGP04.phx.gbl... >> >> All of this inherited from Win16 and, except for the performance >> optimization of using the KM component win32k.sys, has nothing to do with >> the NT kernel - it is the foundation of GDI and every UI element on >> modern Windows (well there is GDI+ too) >> > > Not quite. Because of Win16 cooperative multitasking (essentially single > thread), SendMessage is always in line. The only difference is that it may > cause stack switch. >
From: Alexander Grigoriev on 15 Jan 2010 22:30 Note that SendMessage itself is also a point where the sent messages are handles. "Paul Baker [MVP, Windows Desktop Experience]" <paulrichardbaker(a)community.nospam> wrote in message news:eIJDyvglKHA.5040(a)TK2MSFTNGP06.phx.gbl... > m, > > "m" <m(a)b.c> wrote in message news:uuFwl7XlKHA.1824(a)TK2MSFTNGP04.phx.gbl... > [snip] >> to effectively use SendMessage one must know the following: >> >> 1) The thread that handles the target window (either this thread or any >> other in the system) >> 2) That any remote thread handler does not call SendMessage or use any >> other sync objects that might be owned by the calling thread since >> deadlocks will occur. > > I left #2 off my earlier list that I mostly lifted from documentation :) > > #2 has bitten me a couple of times in the past. Not because I didn't know > it to be true, but partly because it was not forefront in my mind when I > was adding the synchronization objects and partly because it can be > complicated to assess whether existing code is affected. > > (My real problem is that I am mixing complex multi-threaded and > distributed processing with a UI that needs to be synchronized with it, > which is where most of the SendMessage's come in. I am working on > splitting it into a server with no UI and a client with UI). > > Paul >
From: tanix on 16 Jan 2010 00:00 In article <OFO#6wllKHA.2132(a)TK2MSFTNGP05.phx.gbl>, "Alexander Grigoriev" <alegr(a)earthlink.net> wrote: >Note that SendMessage itself is also a point where the sent messages are >handles. Sorry to interfere here. I think if you comment things in place, exactly where it is most logical in the context of what you replying to, it would be more readabe. You are in the expert section and your articles are some of more valuable. Just keep in mind that vast majority of article views are going to be done as a web page. Depending on which version they are looking at, there may not necessarily be the whole thread avaiable to them. Another thing, people spent about 5 seconds to view the articles on average. So, if things are exactly in place, it becomes easier for the user to see if this is something of value to them. The bottom line is: you have about 5 to 10 seconds to deliver your message and with good article formatting, it should all fall into place immediately. Responding as top posting takes things out of context and the article viewer can not see what you are responding to. So, the chances are high he will simply click the "next" button and ignore your article because he can not see instantly what it relates to, what issue it addresses and what point it resolves. >"Paul Baker [MVP, Windows Desktop Experience]" ><paulrichardbaker(a)community.nospam> wrote in message >news:eIJDyvglKHA.5040(a)TK2MSFTNGP06.phx.gbl... >> m, >> >> "m" <m(a)b.c> wrote in message news:uuFwl7XlKHA.1824(a)TK2MSFTNGP04.phx.gbl... >> [snip] >>> to effectively use SendMessage one must know the following: >>> >>> 1) The thread that handles the target window (either this thread or any >>> other in the system) >>> 2) That any remote thread handler does not call SendMessage or use any >>> other sync objects that might be owned by the calling thread since >>> deadlocks will occur. >> >> I left #2 off my earlier list that I mostly lifted from documentation :) >> >> #2 has bitten me a couple of times in the past. Not because I didn't know >> it to be true, but partly because it was not forefront in my mind when I >> was adding the synchronization objects and partly because it can be >> complicated to assess whether existing code is affected. >> >> (My real problem is that I am mixing complex multi-threaded and >> distributed processing with a UI that needs to be synchronized with it, >> which is where most of the SendMessage's come in. I am working on >> splitting it into a server with no UI and a client with UI). >> >> Paul >> > > -- Programmer's Goldmine collections: http://preciseinfo.org Tens of thousands of code examples and expert discussions on C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, PHP, organized by major topics of language, tools, methods, techniques.
From: Boba on 16 Jan 2010 05:20
"Paul Baker [MVP, Windows Desktop Experience]" <paulrichardbaker(a)community.nospam> wrote in message news:uGhoWsglKHA.4408(a)TK2MSFTNGP04.phx.gbl... >... You should be happy that it buffered all those events without losing >them (presumably interrupt based?), if it didn't that would bad. ^ 6 mouse events got lost here >...doing the processing you expect *and* taking key/mouse events promptly. >It just can't. Something has to give. ^ and at least 6 more here d'u use oe or u'r texting while driving :) |