> Date: Tue, 03 Jul 2001 03:17:12 -0700
> From: Terry Lambert <[EMAIL PROTECTED]>
> > 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 <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>, or you are likely to be blocked.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
