lkml.org 
[lkml]   [2002]   [Jun]   [13]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateThu, 13 Jun 2002 11:37:46 +0200
FromPeter Wächtler <>
SubjectRe: [PATCH] Futex Asynchronous Interface
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