Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 Jul 2001 19:54:15 +0000 (GMT)
From:      "E.B. Dreger" <eddy+public+spam@noc.everquick.net>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Chris Costello <chris@calldei.com>, freebsd-smp@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG
Subject:   Re: libc_r locking... why?
Message-ID:  <Pine.LNX.4.20.0107031924220.2378-100000@www.everquick.net>
In-Reply-To: <3B419BA8.3D93EB5A@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Tue, 03 Jul 2001 03:17:12 -0700
> From: Terry Lambert <tlambert2@mindspring.com>

> >         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 <blacklist@brics.com>
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 <blacklist@brics.com>, 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.20.0107031924220.2378-100000>