Messages in this thread | | | From | "David Schwartz" <> | Subject | RE: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow) | Date | Fri, 27 Jan 2006 15:31:59 -0800 |
| |
> David, you specifically have been faced with this question before: > http://groups.google.com/group/comp.programming.threads/browse_frm > /thread/2184ba84f911d9dd/a6e4f7cf13bbec2d#a6e4f7cf13bbec2d > and you didn't dispute the interpretation then. The wording for > pthread_mutex_unlock hasn't changed between 2001 and now.
This was a totally different question. This was about the implementation, not the interpretation. You'll note that I objected to the implementation.
> And here: > http://groups.google.com/group/comp.programming.threads/msg/89cc5d600e34e88a ?hl=en&
Again, I don't see that I commented on the interpretation. This was an unfortunate missed oppurtunity. Kaz is incorrect here.
> If those statements were incorrect, I have a feeling someone would have > corrected them at the time. Certainly you can attest to that.
Obviously not, since they are incorrect and nobody did.
> http://groups.google.com/group/comp.programming.threads/msg/d5b2231ca57bb102 ?hl=en&
Again, this had nothing whatsoever to do with whether the interpretation is correct or not.
> Clearly at this point there's nothing to be gained from pursuing this > any further. The 2.6 kernel has been out for too long; if it were to be > "fixed" again it would just make life ugly for another group of people, > and I don't want to write the autoconf tests to detect the > flavor-of-the-week. We've wasted enough time arguing futilely over it, > I'll stop.
The problem is that this interpretation is simply incorrect and results in maximally inefficient implementations.
David Butenhof recently posted to comp.programming.threads and indicated that disagreed with this implementation. That's about as close to authoritative as you're likely to get.
POSIX had no intention to constrain the scheduler to compel inefficient behavior. In fact, they went out of their way to create the lightest possible primitives.
DS
- 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/
| |