Messages in this thread | | | Date | Sun, 18 May 2003 13:13:55 -0700 (PDT) | From | Davide Libenzi <> | Subject | Re: recursive spinlocks. Shoot. |
| |
On Sun, 18 May 2003, Peter T. Breuer wrote:
> This is essentially the same struct as mine. I used the pid of the task, > where you use the address of the task. You use an atomic count, whereas > I used an ordinary int, guarded by the embedded spinlock. > > > > #define nestlock_lock(snl) \ > > do { \ > > if ((snl)->uniq == current) { \ > > That would be able to read uniq while it is being written by something > else (which it can, according to the code below). It needs protection.
No it does not, look better.
> > atomic_inc(&(snl)->count); \ > > OK, that's the same. > > > } else { \ > > spin_lock(&(snl)->lock); \ > > atomic_inc(&(snl)->count); \ > > (snl)->uniq = current; \ > > Hmm .. else we wait for the lock, and then set count and uniq, while > somebody else may have entered and be reading it :-). You exit with
Nope, think about a case were it breaks. False negatives are not possible because it is set by the same task and false positives either.
> Well, it's not assembler either, but at least it's easily comparable > with the nonrecursive version. It's essentially got an extra if and > an inc in the lock. That's all.
Well, there's a little difference. In case of contention, you loop with your custom try lock while I used the optimized asm code inside spin_lock. But again, I believe we didn't lose anything with the removal of this code (nested/recursive locks) from the kernel.
- Davide
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |