Subj : Re: To anybody at Microsoft who cares... :) To : comp.os.ms-windows.programmer.win32,comp.programming.threads From : Joseph Seigh Date : Sat Jan 08 2005 10:36 am On Sat, 08 Jan 2005 15:47:33 +0100, Alexander Terekhov wrote: > > Ziv Caspi wrote: >> >> Does this help? >> >> Multiprocessor Considerations for Kernel-Mode Drivers >> http://www.microsoft.com/whdc/driver/kernel/MP_issues.mspx > > You mean totally idiotic "ReleaseLock()"? Well, it does sorta help, > just not the way you expect it to help, I'm afraid. ;-) > > Uhmm, just in case... > > http://groups.google.de/groups?selm=41C97341.10A67159%40web.de > http://groups.google.de/groups?selm=41CAF4A6.21D1E051%40web.de > > Hth. > You want to have some sort of generic memory barriers around just in case there's a situation that the other synchronization primatives can't handle or for when you want to create a new synchronization primative and don't want to deal with platform specific memory barriers. 20 versions of memory barrier is overkill. Plus you have the problem that on most platforms the implementation will be stronger than the membar definition and mislead the user into thinking otherwise. So a #Load/Store might be efficient on sparc, but it's going to be MFENCE on ia32/64. The programmer would be better off realizing this and attempting another solution. And you have the problem that people may start using these to define synchronization semantices in terms of a meta memory model that does not exist on any hardware. Joe Seigh .