On Tue, Apr 09, 2013 at 06:28:08PM -0400, Steven Rostedt wrote:
On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote:
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
The thing is now that you're not expected to hold these locks for a long time - if you need to synchronously stall while holding a lock performance will go down the gutters anyway. And since most current gpus/co-processors still can't really preempt fairness isn't that high a priority, either. So we didn't think too much about that.
Yeah but you're proposing a new synchronization primitive for the core kernel.. all such 'fun' details need to be considered, not only those few that bear on the one usecase.
Which bares the question, what other use cases are there?
Tbh I don't see any other either - but I agree with Peter and thinking things through and making the api a bit more generic seems to help in clarifying the semantics. Reminds me that I still need to draw a few diagrams ;-) -Daniel