From owner-freebsd-hackers Fri Jun 29 12:56:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id C049A37B401; Fri, 29 Jun 2001 12:56:47 -0700 (PDT) (envelope-from eddy+public+spam@noc.everquick.net) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.10.2/8.10.2) with ESMTP id f5TJue813575; Fri, 29 Jun 2001 19:56:40 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Fri, 29 Jun 2001 19:56:40 +0000 (GMT) From: "E.B. Dreger" To: Bernd Walter Cc: freebsd-smp@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: libc_r locking... why? In-Reply-To: <20010629211818.A17309@cicely20.cicely.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG (Personal CCs trimmed; back to Bernd and cross-posting -smp and -hackers) > Date: Fri, 29 Jun 2001 21:18:18 +0200 > From: Bernd Walter > > Passing a token between threads. When a thread has the token, it may > > assert a lock or a mutex on an object. Again, I subscribe to threads > > being lightweight; cooperative sharing is better than preemptive or > > trying to grab a lock before another thread does. > > A Token may not be enough because writes may be reordered. > Usually a mutex is a lock with some kind of memory barrier. But it _is_ locked. The thread_with_token++ ; thread_with_token %= num_threads ; was oversimplified. It's more like xorl %ecx,%ecx movl thread_with_token,%eax incl %eax cmpl %eax,num_threads movzl %ecx,%eax lock movl %eax,thread_with_token to pass the token, where thread_with_token is in shared memory. Each process does the above. When a process has the token, it's safe to claim mutexes and such without worry of another thread (without token) accessing simultaneously. Mutex/lock ops also have lock asserted. If this is inadequate, then I need to do some head-scratching. > If you can fetch the lock on a CPU you know that the CPU previous > owning the lock has flushed everything up to the point of coherence > of what was written until the lock was released. Here is where I want to learn more about cache coherency, inter-processor interrupts, and APIC programming. I'd imagine that the latter two are lower-level than I'd be using, but I still want to know the "how and why" beneath the scenes. > Memory barriers and the read-modify-write operations (or locked > operations like on ALPHA) are accessible from user code - but I don't > know of any platform independend functions. Nor do I. > > Any good references on MP standard? Is the lock prefix the only way to > > force cache coherency? > > A good explanation for this kind of thing was in "Programming with POSIX > Threads" in Chapter 3.4 "Memory visible between threads". I'll have to check it out. I [believe that I] understand about the inherent races in SMP, but more reading is always better... However, I'm still interested in x86-specific coherency mechanisms. Any info? > I know you are not usung pthreads but the memory problems are the same. Correct. I just wanted to make certain that we were on the same page, no pun intended. Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to , or you are likely to be blocked. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message