![]() | |||||||||||||
Messages in this thread |
Rusty Russell wrote: > In message <Pine.LNX.4.44.0206120946100.22189-100000@home.transmeta.com> you wr > ite: > >> >> >>On Wed, 12 Jun 2002, Peter W=E4chtler wrote: >> >>>For the uncontended case: their is no blocked process... >>> >>Wrong. >> >>The process that holds the lock can die _before_ it gets contended. >> >>When another thread comes in, it now is contended, but the kernel doesn't >>know about anything. >> > > Note also: this is a feature. > > I have a little helper program which can grab or release a futex in a > (mmapped) file. It's great for shell scripts to grab locks. In this > case the helper exits with the lock held, and a later invocation > releases a lock it never held. > > *AND* the lock is persistent across reboots, since it's in a file. > How cool is that! > Don't want to bugg you: but you would have to clean them up in any case when you restart your system of cooperating programs. Posix shmem would be a nice place to store your mmaped file so that it's gone after reboot - but gives "kernel life time". And not that I want to put the futexes down: but now I understand why the PROCESS_SHARED locks on Irix live in the kernel. Yes, perhaps we should provide both and the app can choose what suits best. - 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-03-22 12:26 [W:0.412 / U:0.340 seconds] ©2003-2008 Jasper Spaans | |||||||||||||