mutex ownership (was: Re: [PATCH 19/24] Unionfs: Helper macros/inlines)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2007-01-08 at 13:28 -0800, Andrew Morton wrote:

> Please use mutexes where possible.  Semaphores should only be used when
> their counting feature is employed.  And, arguably, in situations where a
> lock is locked and unlocked from different threads, because this presently
> triggers mutex debugging warnings, although we should find a way of fixing
> this in the mutex code.

Its a fundamental property of a mutex, not a shortcoming. A mutex has an
owner, the one that takes and releases the resource. This allows things
such as Priority Inheritance to boost owners.

'fixing' this takes away much of what a mutex is.

That said, it seems some folks really want this to happen, weird as it
may be. I'm not sure if all these cases are because of wrong designs. A
possible extension to the mutex interface might be something like this:

  mutex_pass_owner(struct task_struct *task);

which would be an atomic unlock/lock pair where the current task
releases the resource and the indicated task gains it. However it must
be understood that from the POV of 'current' this should be treated as
an unlock action.

Ingo, I'd much rather see something like this than the proposed

  mutex_unlock_dont_warn_if_a_different_task_did_it()

wart. Esp. since it preserves the mutex semantics and properties.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux