Date: Sat, 16 Nov 1996 03:36:41 +1100 From: Bruce Evans <bde@zeta.org.au> To: jdp@polstra.com, michaelh@cet.co.jp Cc: hackers@FreeBSD.ORG Subject: Re: Programming technique for non-forking servers? Message-ID: <199611151636.DAA18603@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> mset and mclear would be implemented as lib functions because Intel does >> have an atomic test and set. > >Yes it does: the "xchg" instruction. Load 1 into a register, then "xchg" >the register with the memory location containing the lock. Look at the >new value of the register to find out whether the lock was already >locked. It also has many other instructions suitable for locking primitives: bt, btc, btr, bts (386 up) sal (386 up) (standard trick) cmpxchg (486 up) xadd (486 up) cmpxchg8b (Pentium (up?)) >It even works in a multiprocessor system. According to the >Intel book: > If a memory operand is involved, the LOCK# signal is asserted for the > duration of the exchange, regardless of the presence or absence of the > LOCK prefix or of the value of the IOPL. I think the other instructions work in multiprocessor systems if they have a `lock' prefix. The optional locking makes them more useful on uniprocessors (actually, except for `sal' they are usually too slow to be worth using except for locking. E.g., on Pentiums `bt' of a memory variable takes 26 times as long as a simple instruction). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611151636.DAA18603>