>>>>> "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
LT> Uri Guttman <[EMAIL PROTECTED]> wrote: >> >>>>> "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes: LT> These are platform specific details. We will use whatever the LT> platform/OS provides. In the source code its a LOCK() UNLOCK() pair. LT> The LOCK() can be any atomic operation and doesn't need to call the LT> kernel, if the lock is aquired. >> if it doesn't call the kernel, how can a thread be blocked? LT> I wrote, *if* the lock is aquired. That's AFAIK the fast path of a futex LT> or of the described Win32 behavior. The slow path is always a kernel LT> call (or a some rounds spinning before ...) LT> But anyway, we don't reinvent these locking primitives. ok, i missed the 'if' there. :) that could be workable and might be faster. it does mean that locks are two step as well, user space test/set and fallback to kernel lock. we can do what nigel said and wrap the test/set in macros and use assembler to get at it on platforms that have it or fallback to dijkstra on those that don't. uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
