From owner-freebsd-current Tue Mar 11 08:40:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA17674 for current-outgoing; Tue, 11 Mar 1997 08:40:34 -0800 (PST) Received: from ui-gate.utell.co.uk (ui-gate.utell.co.uk [194.200.4.253]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA17658 for ; Tue, 11 Mar 1997 08:40:21 -0800 (PST) Received: from shift.lan.awfulhak.org (shift.utell.net [97.3.0.21]) by ui-gate.utell.co.uk (8.7.6/8.7.3) with ESMTP id QAA28986; Tue, 11 Mar 1997 16:39:49 GMT Received: from shift.lan.awfulhak.org (localhost [127.0.0.1]) by shift.lan.awfulhak.org (8.8.5/8.8.5) with ESMTP id QAA27876; Tue, 11 Mar 1997 16:41:10 GMT Message-Id: <199703111641.QAA27876@shift.lan.awfulhak.org> X-Mailer: exmh version 1.6.9 8/22/96 To: Bruce Evans cc: ache@nagual.ru, brian@awfulhak.demon.co.uk, brian@utell.co.uk, current@freebsd.org Subject: Re: ppp In-reply-to: Your message of "Wed, 12 Mar 1997 03:16:27 +1100." <199703111616.DAA20223@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Mar 1997 16:41:10 +0000 From: Brian Somers Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >&= ~ isn't guaranteed atomic ? Yeuch. I'd tend to go with Andrey's > > Nothing is guaranteed to be atomic in C. The closest it gets is > objects of type sig_atomic_t, which can safely be set (but not read) > in signal handlers. Oh boy, I've written *lots* of code in the past that assumes ++ and -- to be atomic - I kinda assumed that it had to reduce to an inc or dec, but then, I've seen some of the assembler output by gcc before - and it's the best compiler I've seen. Oh well, you learn something new..... > >suggestion that I use an int array rather than a bit array. I assume > >that ++ and -- are guaranteed to be atomic (if they're not, I'm in *lots* > >of trouble). > > No, ++ and -- guaranteed to be atomic. They are good candidates for > splitting up into read/modify/write so that they can be pipelined better. > In practice, the i386 version of gcc is usually too stupid to do this. > > The kernel handles the corresponding problems for interrupts by using > assembler code to get instructions that are known to be atomic. It > could also use some form of locking, but locking tends to be slower. > Kernel locking using splhigh()/splx() corresponds exactly to > sigprocmask(SIG_BLOCK...)/sigprocmask(SIG_SETMASK...). > > Bruce I think the sigprocmask stuff is impractical. It would take a relatively long time to SIG_BLOCK all the signals before altering caused each time. I'll do without. The only thing that can happen as a result is a lost signal, and that's what I'd get on a slow machine anyway. At least the code will be handling practically all latencies introduced by the pending signal. -- Brian Don't _EVER_ lose your sense of humour !