quote:Original post by Magmai Kai Holmlor
In posix term, the code between the mutex lock and unlock is called a critical section . This is the code that must be syncronized.
It''s feasible for a *nix to provide a process-local mutex, but don''t bet on it. After you write threaded (and socket) code for Win32, you''ll wonder how they make anything work in the *nix world (or at least I do).
It''s actually rather easy to write your own mutex code with a tiny bit of assembly...using the BTS instruction.
Two functions from my ''Mutex'' class:
void Mutex::Lock( void ){ register unsigned char rtn; do { asm ("bts %1, %0" : "+r" (LockData) : "r" (0) ); asm ("setc %0" : "+r" (rtn) ); } while ( rtn ); //loops until we aquire the mutex}void Mutex::Unlock( void ){ LockData = 0;}
I only call these from my lock class, which locks and unlocks as it constructs and destructs.
LockData is an integer in my code... I''m assuming a char would work fine.
If you want to squeese as much space out as possible, it''s possible to have a mutex for every bit of the char/int/whatever. All that needs changing is a single parameter, the "r" (0) part. This selects the first bit... to select the second, you''d place "r" (1). The third would be "r" (2) and so forth...
BTS sets the bit and places the original value in the carry bit in an atomic action. the second instruction (setc) saves the original result to the rtn variable, so we can see if we got the mutex. If it''s 1, then no, it was allready being used, and thus setting it to 1 didn''t do anything. If it''s 0, then we just set it to 1, and it''s our mutex now. Muahahahahha!
ok...ill shutup now....
) while Mutex operates on Kernel level always. 
