![]() | |||||||||||||
Messages in this thread |
On Fri, 2005-12-16 at 14:19 -0800, Linus Torvalds wrote: > > On Fri, 16 Dec 2005, Thomas Gleixner wrote: > > > > Well, in case of a semaphore it is a semantically correct use case. In > > case of of a mutex it is not. > > I disagree. > > Think of "initialization" as a user. The system starts out initializing > stuff, and as such the mutex should start out being held. It's that > simple. It _is_ mutual exclusion, with one user being the early bootup > state. Mutual exclusion is available with various semantical characteristics. If you want to have a particular semantical functionality you have to chose a variant which fits that need. Arguing that the underlying mechanism (implemenation) can handle your request is broken by definition. It can, but it still is semantically wrong. Mutexes have a well defined semantic of lock ownership, i.e. the thread which locked a mutex has to unlock it. Semaphores do not have this semantical requirement. Therefor, if you want to handle that "init protection" scenario, do not use a mutex, because the owner can not be defined at compile - allocation time. You can still implement (chose a mechanism) a mutex on top - or in case of lack of priority inheritance or debugging with exactly the same - mechanism as a semaphore, but this does not change the semantical difference at all. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-12-16 23:38 [from the cache] ©2003-2008 | |||||||||||||