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. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
