l4-hurd
[Top][All Lists]
Advanced

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

Re: reuse of task IDs


From: Marcus Brinkmann
Subject: Re: reuse of task IDs
Date: Mon, 5 May 2003 21:13:04 +0200
User-agent: Mutt/1.5.3i

On Mon, May 05, 2003 at 08:41:09PM +0200, Espen Skoglund wrote:
> [Marcus Brinkmann]
> > There are many other similar races: How does a server guarantee that
> > it is getting the RPC from the iedntical task which got the send
> > right?  How, in a handle transaction, does B guarantee it is using
> > the same server that A used?  Every protocol involving two threads
> > and RPCs from one thread to another has to deal with this issue of
> > reused thread and task ids.  And I am not happy.
> 
> Just as a note: the reason for introducing the version part in thread
> IDs was exactly to overcome situations like this, i.e., to identify
> that one is communicating with or operating on the expected thread.

I realize that, however, the version ID is just 14 bits on 32 bit machines,
and that is 2^14 = 16384.  It is simple to create and destroy 16384 quickly
to force reuse (if that's how thread ids are allocated).

Only if you would use a high resolution time stamp counter as version id you
would have the robustness I would expect.

> If dealing with situations like this without making use of the version
> part proves too problematic or inefficient you might want to
> reconsider the scheme of mapping task IDs onto version numbers?

Well, looking at it the other way: We are using the version ID for exactly this
purpose.  The version ID is the PID.  The PID has the same requirement that
it shouldn't be reused early (think about "kill N" where N is a task that
dies just before you press the enter key - you don't want N to be reused
early).  So, task IDs are allocated the same way that you would allocate a
version ID if it weren't a task ID, except with a lower resolution (ie, we
don't bump the version ID up by 1, but by some small number K which bumps it
to the next PID to be used).  However, as I said above, even if we would use
the finest resolution available, it would not be acceptable because of the
limited bits available for version ID.

Now, give me a 64-bit machine and I might stop argueing :)  Seriously, using
the PID as version ID is just too darn convenient to give it up.  In a 64
bit machine, one could use a part of the thread number as task ID, and then
use the version ID for what it is intended.  Even then the race window would
be only a couple of hours to days in an extreme situation, but it would be
much better than what we have to deal with on ia32.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]