Date: Sun, 1 Jul 2001 15:49:33 +0300 From: Valentin Nechayev <netch@iv.nn.kiev.ua> To: "E.B. Dreger" <eddy+public+spam@noc.everquick.net> Cc: Terry Lambert <tlambert2@mindspring.com>, Chris Costello <chris@calldei.com>, freebsd-smp@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: libc_r locking... why? Message-ID: <20010701154933.B376@iv.nn.kiev.ua> In-Reply-To: <Pine.LNX.4.20.0106291334350.7587-100000@www.everquick.net>; from eddy%2Bpublic%2Bspam@noc.everquick.net on Fri, Jun 29, 2001 at 03:19:47PM %2B0000 References: <3B3C3346.E5496485@mindspring.com> <Pine.LNX.4.20.0106291334350.7587-100000@www.everquick.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Fri, Jun 29, 2001 at 15:19:47, eddy+public+spam (E.B. Dreger) wrote about "Re: libc_r locking... why?": > Running processes on multiple CPUs is one goal. > > [ libc_r locks don't assert "lock", not MP-safe ] > > So the "lock" prefix is the only way to enforce cache coherency? > Do you have handy a good reference on IPIs, other than the kernel > APIC code (and, of course, Google and NorthernLight searches)? You say about i386 architecture, don't you? All current and former processors has AFAIK strict write ordering, and cache coherency is provided for all data. If lock is obtained, it means that all previous data is written successfully and caches of other processors are notified for your changes. Use locks and don't worry for cache coherency, it is already done. > Good to know, but, I'm not using libc_r... I was looking at > existing code to help me double-check mine as I go. I'm > synchronizing processes with a "giant lock" token that each > process cooperatively passes to the next... to simplify: Did you check your code with some proven to be working between processes, e.g. SysV IPC semaphores? /netch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010701154933.B376>