Messages in this thread | | | Subject | Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation | From | Thomas Gleixner <> | Date | Fri, 16 Dec 2005 23:42:44 +0100 |
| |
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/
| |