Hi, While I find using the PFN lock to synchronize access to control areas ridiculous in general, I wouldn't dare to expect anyone to design a better locking architecture. My point here is basically that for setting a single flag (and derived from it's name this function has obviously no other purpose than setting this flag), without any checks or anythig else, using a lock is not how you do it. And you probably know how much I love the "Windows does it" argument...
Timo Am 02.11.2013 10:48, schrieb Pierre Schweitzer: > Hey, > > yes, it can sound weird (especially because in some other places where > we use the ControlArea, we don't lock it), BUT, three reasons here: > -> We change flags (let's ensure there's only one change at a time) > -> Windows does it > -> Microsoft documents it: > http://download.microsoft.com/download/7/E/7/7E7662CF-CBEA-470B-A97E-CE7CE0D98DC2/mmwin7.pptx > > "PFN Lock : The Scope -> All control area, segments, subsections and > prototype PTE usage". > > But even themselves criticize such usage (hence its removal in Win7). > > Regards, > > On 02/11/2013 00:38, Timo Kreuzer wrote: >> Am 31.10.2013 00:17, schrieb pschweit...@svn.reactos.org: >>> +VOID >>> +NTAPI >>> +MiSetControlAreaSymbolsLoaded(IN PCONTROL_AREA ControlArea) >>> +{ >>> + KIRQL OldIrql; >>> + >>> + ASSERT(KeGetCurrentIrql() <= APC_LEVEL); >>> + >>> + OldIrql = KeAcquireQueuedSpinLock(LockQueuePfnLock); >>> + ControlArea->u.Flags.DebugSymbolsLoaded |= 1; >>> + >>> + ASSERT(OldIrql <= APC_LEVEL); >>> + KeReleaseQueuedSpinLock(LockQueuePfnLock, OldIrql); >>> + ASSERT(KeGetCurrentIrql() <= APC_LEVEL); >>> +} >> No offence, but seriously? The PFN lock to set a flag? >> >> >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
