This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [parisc-linux] Re: [PATCH] Fix the atomic compare and swap
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: libc-ports at sourceware dot org, aurelien at aurel32 dot net, parisc-linux at lists dot parisc-linux dot org
- Date: Mon, 21 May 2007 14:30:34 -0400
- Subject: Re: [parisc-linux] Re: [PATCH] Fix the atomic compare and swap
- Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=mmH3hxhUX1iAswhL6Vi+Muqt2kjZhk3mATv9QoJeAfg6CUGgra0t0fK8/+qsFUQB/x2fpKRpn9PQ11ij6zi/vAOL0ryLE9FUxR6pmSuDLF2apEoj0iGTtXUU/00uFHy8ZgwOEEUHFpKbDa59ze27VyOGQCqxCRwjoSvbd61qH+s=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=hLBX+jhjPum9ljB/zY2tbtx7JGrKJRXwP5F43LMqvsyysw56DX9M7Jp5VagX0zA6w34GFUuwF0yt3U0uSRFgKSSGbSGkDVpFxda0r6cJvR4jV9BVkxXOzwUVep8BbQxYdzL/NEmLfxbckWUAu/vTimBncvU4eXhElW3P1djeG9c=
- References: <119aab440705211019s1b62504epd54a585e5c473b5f@mail.gmail.com> <200705211819.l4LIJoVs021370@hiauly1.hia.nrc.ca>
On 5/21/07, John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:
In the linuxthread case, user spinlock code would typically spin a
few times and then call nanosleep. If this fails a few times, the code
calls sched_yield. From a performance standpoint, I don't think it helps
to waste time in the loop itself.
Yielding the cpu is intended to allow the other threads to make
progress on this or other cpus. It would be wasetful to busy wait your
entire time slice on your cpu, while another thread on another cpu is
doing an LWS CAS.
On the otherhand, the atomic operations on the gateway page are short,
and processes on the gateway page are never supposed to be scheduled
off or sent signals. So, I think a contended lock is only possible
with a SMP kernel.
That is correct. A contended lock is only possible on SMP. This issue
only arose when we started using LWS CAS on the 64-bit SMP systems
available as debian build servers. A UP kernel never retruns EAGAIN.
> I hadn't considered this code would be an external API, but I guess it
> is... so these defines should probably go away and the constants
> merged into the code?
Yah, this just occurred to me. It would be nice if the code could
use EAGAIN from errno.h but I can see that that's a bit tricky.
Possibly, a macro argument would work.
I don't want to be at the *whim* of users who might redefine EAGAIN. I
think the value should be fixed and immutable.
Comments?
Cheers,
Carlos.