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

[Johnny Billquist <bqt%softjar.se@localhost>]

On 2010-11-13 04:49, Matt Thomas wrote:
> On Nov 12, 2010, at 7:39 PM, Johnny Billquist wrote:
> > Eh...?
> > 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
> expensive.

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 
> > locks...
>
> 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

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