ASM Community

initialization: InitializeCriticalSectionAndSpinCount()

ThreadProc code:

1) EnterCriticalSection()
2) do the work
3) LeaveCriticalSection()

deinitialization: DeleteCriticalSection()

much shorter, much better and guaranteed to work even on 78 CPUs :)

Wow did you try it on a 78 cpu computer?  ;)

You can modify your code to use xadd or xchg, too.

RequestAccess proc pLock:PTR DWORD
@@:
mov ecx,pLock
mov eax,1
xadd dword ptr,eax
inc eax
jz @GotAccess
invoke Sleep,0
jmp @B
@GotAccess:
ret
RequestAccess endp

LockVar proc pLock:PTR BYTE
@@:
mov al,1
mov ecx,pLock
xchg byte ptr,al
or al,al
jz @GotAccess
invoke Sleep,0
jmp @B
@GotAccess:
ret
LockVar endp

Critical sections are good, since they also check which thread is requesting access to them, thus

some proc
invoke EnterCriticalSection,addr csect
invoke EnterCriticalSection,addr csect
ret
some endp

will run perfectly. Only that a critical_section takes 24 bytes ^^', instead of 1 or 4.


On PCs with 2 or more cpus, it's good to use a "spin lock loop" - before going to "Sleep,0". EnterCriticalSection has it implemented: it tries to lock the critical_section ~4000 times, before calling Sleep(). On single-cpu systems, the "spin count" value is 0 (set by Windows automatically).

The "lock" prefix:
This instruction is a prefix that causes the CPU assert bus lock
        signal during the execution of the next instruction.  Used to
        avoid two processors from updating the same data location.  The
        cpu always asserts lock during an XCHG with memory operands.  This
        should only be used to lock the bus prior to XCHG,  MOV, IN and
        OUT instructions.

Also, it's worth mentioning that (unless my memory fails me), critical sections don't just sleep after spinning - they do a blocking wait, which takes no CPU time.

I guess it depends on how you look at it. Sleep(0) won't give lower-priority threads a chance, and will still give a (somewhat artificial) CPU usage of 100%. Sleep(1) (or some other small amount) is better. This would still end up wasting cycles though, especially if the thread is going to block for a larger amount of time. You can reduce the amount of cycles wasted by increasing the Sleep() amount, but that gives a higher latency.

On the other hand, blocking on an object really does take 0% CPU time while the thread is blocking - it's removed from the scheduler's ready-list, and thus isn't even considered for execution. Only when the object is triggered will the scheduler spend time on the thread - by iterating through the object's "waiting for trigger" list and re-activating the threads (unless they're also waiting on other condition(s)).

The method to choose, of course, depends on how long you're likely to be waiting for the object to trigger. If you almost never have to wait for the object, CRITICAL_SECTION is good because of it's spin-then-wait strategy. If you'll almost always have to wait, doing WaitForSingleObject right away could be better. And if you're doing some kernel-level driver stuff and must have as low latency as possible (at the expense of burning cycles), spinlock without blocking waits can be appropriate.

But Sleep(0) is the devil :)

thanks for your comments...
so critical sections might be the way to go, unless
my source with a lock prefix would be ok, i assume.
Dom