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

[Matt Thomas <matt%3am-software.com@localhost>]

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.

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

>>>>> Just to be clear - I'm still not in any way saying that machines using
>>>>> CAS today should stop using it. What I was asking for was just a
>>>>> smoother way for machines that don't have CAS to have a way to implement
>>>>> the services used in other ways that would make more sense on those
>>>>> machines, while still providing the same end result.
>>>> 
>>>> Without CAS or an equivalent instruction, you pretty much can't do lockless
>>>> update to datastructures.  I would not expect to see use of CAS disappear
>>>> from the NetBSD kernel, since on modern architectures one really wants to
>>>> do more things without taking locks whenever possible -- not less.
>>> 
>>> Agreed. But implementing a lock can be done without CAS.
>> 
>> I think the problem is that a mutex is more than a simple semaphore
>> and the VAX interlocked instructions are just too primitive to
>> implement it cleanly.  At one time we had a very VAX-centric mutex
>> implementation but it just didn't work correctly 100% of the time.
>> So I choice slow correctness over fast incorrectness.  If you can
>> come up with a better algorithm, by all means do so.  But it has be
>> correct.  The mutex and rwlock definitions are port-specific so you
>> can change them but my experience found it wasn't worth it.
> 
> Please enlighten me to what the actual problem is that you seem to be 
> referring to here. Since I don't think I have a clue. Combining rasing the 
> SPL, and using bit test and set interlock instructions should be totally 
> correct all the time. Just as much as a CAS would be (in combination with a 
> raised SPL, or else the CAS solution will potentially deadlock on interrupts 
> as well).
> 
> And I think that mutexes in NetBSD at the moment possibly can be implemented 
> in a totally port-specific manner (still working on it), rwlocks can't.
> Unless you mean I should totally rip out kern_rwlock.c, and totally provide 
> my own.
> 
>>>> 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.