Messages in this thread | | | Subject | Re: [RFC PATCH] mutex: Documentation rewrite | From | Tim Chen <> | Date | Wed, 21 May 2014 12:02:56 -0700 |
| |
On Wed, 2014-05-21 at 10:41 -0700, Davidlohr Bueso wrote: > From: Davidlohr Bueso <davidlohr@hp.com> > > Our mutexes have gone a long ways since the original implementation > back in 2005/2006. However, the mutex-design.txt document is still > stuck in the past, to the point where most of the information there > is practically useless and, more important, simply incorrect. This > patch pretty much rewrites it to resemble what we have nowadays. > > Since regular semaphores are almost much extinct in the kernel > (most users now rely on mutexes or rwsems), it no longer makes > sense to have such a close comparison, which was copied from most > of the cover letter when Ingo introduced the generic mutex subsystem. > > While users who really want to learn more about kernel mutexes can > go and read the code, I have marked this RFC since I'm sure more gory > details can be included. Also, ww_mutexes are intentionally left out, > leaving things as generic as possible. > > Comments welcome!
Thanks for doing this.
> + > +(iii) slowpath: last resource, if the lock is still unable to be acquired
change "last resource" to "last resort"
> > Disadvantages > ------------- > > -The stricter mutex API means you cannot use mutexes the same way you > -can use semaphores: e.g. they cannot be used from an interrupt context, > -nor can they be unlocked from a different context that which acquired > -it. [ I'm not aware of any other (e.g. performance) disadvantages from > -using mutexes at the moment, please let me know if you find any. ] > -
Should we keep this instead of deleting it? It is still true we cannot use mutex from an interrupt context.
Tim
| |