On Tue, Apr 2, 2013 at 6:59 PM, Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> wrote: >> > Also, is there anything in CS literature that comes close to this? I'd >> > think the DBMS people would have something similar with their >> > transactional systems. What do they call it? > >> I didn't study cs, but judging from your phrasing I guess you mean you >> want me to call it transaction_mutexes instead? > > Nah, me neither, I just hate reinventing names for something that's > already got a perfectly fine name under which a bunch of people know > it. > > See the email from Daniel, apparently its known as wound-wait deadlock > avoidance -- its actually described in the "deadlock" wikipedia > article. > > So how about we call the thing something like: > > struct ww_mutex; /* wound/wait */ > > int mutex_wound_lock(struct ww_mutex *); /* returns -EDEADLK */ > int mutex_wait_lock(struct ww_mutex *); /* does not fail */ I'm not sold on this prefix, since wound-wait is just the implementation detail of how it detects/handles deadlocks. For users a really dumb strategy of just doing a mutex trylock and always returning -EAGAIN if that fails (together with a msleep(rand) in the slowpath) would have the same interface. Almost at least, we could ditch the ticket - but the ticket is used as a virtual lock for the lockdep annotation, so ditching it would also reduce lockdep usefulness (due to all those trylocks). So in case we ever switch the deadlock/backoff algo ww_ would be a bit misleading. Otoh reservation_ is just what it's used for in graphics-land, so not that much better. I don't really have a good idea for what this is besides mutexes_with_magic_deadlock_detection_and_backoff. Which is a bit long. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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
