Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Jun 2001 21:18:18 +0200
From:      Bernd Walter <ticso@mail.cicely.de>
To:        "E.B. Dreger" <eddy+public+spam@noc.everquick.net>
Cc:        Bernd Walter <ticso@mail.cicely.de>, Peter Pentchev <roam@orbitel.bg>, 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:  <20010629211818.A17309@cicely20.cicely.de>
In-Reply-To: <Pine.LNX.4.20.0106291838250.12068-100000@www.everquick.net>; from eddy%2Bpublic%2Bspam@noc.everquick.net on Fri, Jun 29, 2001 at 06:44:29PM %2B0000
References:  <20010629203351.A16557@cicely20.cicely.de> <Pine.LNX.4.20.0106291838250.12068-100000@www.everquick.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 29, 2001 at 06:44:29PM +0000, E.B. Dreger wrote:
> > Date: Fri, 29 Jun 2001 20:33:51 +0200
> > From: Bernd Walter <ticso@mail.cicely.de>
> > 
> > I can't see how you make shure that on SMP systems all CPUs have
> > the same meaning from memory content.
> > Normaly you would use a mutex or similar before accessing a data range
> > from another thread which also enshures that the CPU specific caches 
> > and buffers are syncronised.
> > If you don't do this it may happen that you write a variable and
> > another thread uses this variable using another CPU before the first
> > CPU has writen this memory seeable for others and works with an
> > outdated content.
> 
> 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.
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.
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.

> 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 know you are not usung pthreads but the memory problems are the same.

> 
> 
> 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 <blacklist@brics.com>
> 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 <blacklist@brics.com>, 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

-- 
B.Walter              COSMO-Project         http://www.cosmo-project.de
ticso@cicely.de         Usergroup           info@cosmo-project.de


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010629211818.A17309>