tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Please do not yell at people for trying to help you.

On 2010-11-13 04:49, Matt Thomas wrote:

On Nov 12, 2010, at 7:39 PM, Johnny Billquist wrote:

Now I'm not following you.
Yes, if you grab a lock in some code, and then get an interrupt, and in that 
interrupt routine, you try to grab the same lock, you loose.
That should be pretty obvious.
How does using CAS to implement a lock change that???

because CAS will not hang.  That's one reason it's great for lockless
primitives.  CAS always returns the old value.  It's up to the caller
to determine how to deal with that.  But you don't spin trying to
look at it.

The BBSSI instruction don't "hang" either. It completes, and either takes a jump, or not. It is up to you to decide what to do at that point. if you just do a branch back to the BBSSI, then you are indeed spinning, but that is just like doing a CAS, followed by a test, and then jump back to the CAS again. A spin lock is exactly this. You just repeat the test over and over again, until it hopefully succeeds.

I still totally fail to see that BBSSI is a problem.

But as I said before. Implementing a mutex on a VAX, is really simple.

Sure.  If you only care about slow uniprocessors, implementing a mutex
is simple.

Huh? The above code is MP safe, and *really* simple. Why do you assume that I'm 
only talking uniprocessor code here?

If you don't have to worry about synchronization on multiple IPLs.

If you just are referring to the fact that you can get deadlocks, then that is 
always an issue with IPL on your own CPU. And that is why our spin lock mutexes 
have an associated IPL, which we must go up to when grabbing one as well. This 
is not some inherent problem with the VAX locking code solution, but a problem 
with locks/mutexes in relationship to interrupts, no matter how you implement 
your locks/mutexes.

but our locking code doesn't rely on spinlocks since they are

It sure do. Look at what a spin mutex is...

Given that, I can't see the benefit to removing one particular use of
atomic CAS in our kernel -- and I can see a great deal of reason _not_ to
prohibit MI code from creating more.

Removing CAS from the locking code is a place where we could see serious gain 
for architectures not having a CAS. At the same time, having a design that 
allows you to use CAS for the locking code, if that fits the bill means noone 
should loose from such a solution. There could (should) only be winners.

Eventually, most operations come down to compare and swap.  It's just too
damn useful to not have as a primitive.  Even if some of the platforms
have to emulate it somehow.  Just because an architecture is 30+ years old
doesn't mean we are forced to ignore algorithms that came after its birth.

Hmm. I don't agree. Some operations just comes down to a test and set. Like 

simple locks are not mutexes.  mutexes are more complex and
test-and-set isn't adequate to do the job.

I (obviously) totally disagree... :-)
A mutex is simply just an object that only one entity can own at a time. Hence "mutex", or mutually exclusive. A test-and-set is precisely all that is needed to implement this. And if you implement a mutex with spin locking, then you also need to make sure that you do not get deadlocks. Either by detecting such things, or make sure they don't happen. But that is outside the subject of the test-and-set part.


Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email:             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Home | Main Index | Thread Index | Old Index