From owner-freebsd-smp Tue Jul 3 12:54:52 2001 Delivered-To: freebsd-smp@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id 7E97437B405; Tue, 3 Jul 2001 12:54:43 -0700 (PDT) (envelope-from eddy+public+spam@noc.everquick.net) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.10.2/8.10.2) with ESMTP id f63JsGf02843; Tue, 3 Jul 2001 19:54:16 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Tue, 3 Jul 2001 19:54:15 +0000 (GMT) From: "E.B. Dreger" To: Terry Lambert Cc: Chris Costello , freebsd-smp@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: libc_r locking... why? In-Reply-To: <3B419BA8.3D93EB5A@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Date: Tue, 03 Jul 2001 03:17:12 -0700 > From: Terry Lambert > > who_has_lock++ ; > > who_has_lock %= process_count ; > > Your unsimplified assembly is not happy, and neither is > this. You want to use a LOCK CMPXCHG to implement your > mutexes; the LOCK prefix makes it a barrier instruction, > which is needed to ensure that two processors don't operate > on their L1 cache contents, and then both attempt to write > back, where one wins the race, but both think they own the > lock. So I see now. Brainstorming, something like: ;; eax = my id to match with token movl $my_id,%eax ;; ecx = next process = (my_id + 1) % process_count xorl %edx,%edx leal 1(%eax,1),%ecx lock cmpl $process_count,%ecx movzl %edx,%ecx ;; edx = my id, for use after cmpxchg ;; if ( who_has_lock == my_id ) who_has_lock = ecx movl %eax,%edx lock cmpxchg %ecx,$who_has_lock ;; see what happened cmpl %edx,%eax jnz *we_didnt_have_the_token I'll look at the kernel code, compare with the above, and run with it. Thanks for beating on my head with a bigger hammer until things clicked. :-) I've bookmarked a page of "dangerous" instructions that require the lock prefix. > > If a thread has nothing to do, I nanosleep(2) to prevent the critical > > path from degenerating to an extended spin. I'm considering using > > socketpair(2)s, with a process blocking indefinitely on read(2) until > > another process write(2)s to awaken it... > > This would work, but it will destroy your SMP scaling > that you want to achieve, since you will effectively > serialize your processes running. Typo on my part. If a _process_ has nothing to do, I put the thing to sleep. I presume that it's [at least sometimes] better to have a sleeping process than to have to launch a new process. 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 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 , or you are likely to be blocked. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message