On Mon, May 27, 2013 at 12:01:50PM +0200, Maarten Lankhorst wrote:
Again, early.. monday.. would a trylock, even if successful still need the ctx?
No ctx for trylock is supported. You can still do a trylock while holding a context, but the mutex won't be a part of the context. Normal lockdep rules apply. lib/locking-selftest.c:
context + ww_mutex_lock first, then a trylock: dotest(ww_test_context_try, SUCCESS, LOCKTYPE_WW);
trylock first, then context + ww_mutex_lock: dotest(ww_test_try_context, FAILURE, LOCKTYPE_WW);
For now I don't want to add support for a trylock with context, I'm very glad I managed to fix ttm locking to not require this any more, and it was needed there only because it was a workaround for the locking being wrong. There was no annotation for the buffer locking it was using, so the real problem wasn't easy to spot.
Ah, ok.
My question really was whether there even was sense for a trylock with context. I couldn't come up with a case for it; but I think I see one now.
The thing is; if there could exist something like:
ww_mutex_trylock(struct ww_mutex *, struct ww_acquire_ctx *ctx);
Then we should not now take away that name and make it mean something else; namely: ww_mutex_trylock_single().
Unless we want to allow .ctx=NULL to mean _single.
As to why I proposed that (.ctx=NULL meaning _single); I suppose because I'm a minimalist at heart.