Dynamic reads without locking.

Bernd Walter ticso at cicely12.cicely.de
Wed Oct 8 05:45:56 PDT 2003


On Wed, Oct 08, 2003 at 02:11:12PM +0200, Harti Brandt wrote:
> On Wed, 8 Oct 2003, Bernd Walter wrote:
> 
> BW>On Wed, Oct 08, 2003 at 12:12:22PM +0200, Pawel Jakub Dawidek wrote:
> BW>> But I'm not talking about non-atomic reads. What I'm want to show is that
> BW>> even atomic read (without lock) is dangerous in some cases.
> BW>
> BW>The above mtx_lock/read/mt_unlock case doesn't make sense, because it
> BW>only garanties an up to date value, but you cache it in a local
> BW>variable which again brings it out of date when used outside the lock.
> 
> You might (for what ever reason) not care that the value gets out of date
> later on, but care that it is correct and consistent in itself. In this
> case, if foo is large (64-bit or a structure) the mtx_lock/read/mtx_unlock
> makes perfect sense because it guarantees that the value is not changed
> while you're copying it (non-atomically).

We agree here, but the topic was for atomic reads.
If you read a 64 bit value you have to be shure that 64 bit values can
be read atomicaly and if they are also written atomicaly then there is
no reason to worry about the cosistency of the value itself.
I'm not shure if 64 bit values are atomic on all platforms, but they
are on some - at least on alpha.
On all our platforms reading and writing 8, 16 and 32 bit values should
be atomic if they are naturaly aligned - correct me if I'm wrong.
Well if you write a 32 bit value with byte acces (e.g. with byte order
macros), then you are lost even with a atomic 32 bit read.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso at bwct.de                                  info at bwct.de



More information about the freebsd-hackers mailing list