[concurrency-interest] ITL and revised ThreadContext

Dawid Kurzyniec dawidk@mathcs.emory.edu
Fri, 9 Jan 2004 03:11:52 -0500

> -----Original Message-----
> From: concurrency-interest-admin@cs.oswego.edu 
> [mailto:concurrency-interest-admin@cs.oswego.edu] On Behalf 
> Of Doug Lea
> Sent: Thursday, January 08, 2004 8:53 PM
> To: Dawid Kurzyniec
> Cc: concurrency-interest@altair.cs.oswego.edu
> Subject: Re: [concurrency-interest] ITL and revised ThreadContext
> Dawid,
> As always, I'm truly sympathetic about the problems you and 
> others face trying to develop efficient secure middleware. 
> But, as always, there are a lot of forces opposing simple solutions.
> Your revised proposal does look like it meets some of the 
> objections in previous exchanges. I think the main remaining 
> one is defining exactly what is in ThreadContext. To do this 
> right, class Thread would either need to be a subclass of 
> ThreadContext, or have a guaranteed ThreadContext 
> constituent. Otherwise, there would be two unrelated classes 
> that would need to be kept in sync, which is asking for 
> trouble. (And at this point is not something we can sneak 
> into JSR166.)

(Quick note: inheritance does not seem right since the relation is not
that thread "is" the context but more that context is an immutable
"snapshot" of a thread inheritable state. My original proposal, whether
it makes sense or not, was to make Context an inner class of Thread, and
to define "getCurrentContext()" and "perform()" as static methods of

I understand and appreciate the reasons why you don't want to push it
into JSR166 at this late stage. Pity I haven't got into the trouble a
year earlier - then maybe I have succeeded by now in lobbying you into
the idea :)

Nevertheless, your response suggests that the main objections against
this proposal are not that the approach is incorrect or bad, but that
there is simply not enough time to complete (and gain some confidence
about) the design for inclusion in incoming 1.5 release. Assuming that
the work on java.util.concurrent will continue, however, I am asking you
to not forget about us, poor middleware people, and come back to the ITL
issue eventually. (Hopefully this mailing list will continue to work as
a j.u.c. users forum).

In the meantime, I think I have found a workaround which should work for
me at the moment (with JDK 1.4, or even earlier). It seems to be
possible to define a ThreadContext utility class as I am describing
completely in a user space, and to furnish a subclass of
InheritableThreadLocal in a way that such ThreadContext propagates those
locals. This does not help with legacy code which uses
j.l.InheritableThreadLocals, but nevertheless it enables new code to be
written to work with thread pools and propagating the locals as long as
they are created as instances of the new subclass. I will probably
submit the (surprisingly compact) implementation, to get some feedback
and maybe for the benefit of other people who also miss that feature,
once I become convinced that it works as expected.

> While I'm at it.... It occurred to me after our last set of 
> discussions on related issues that, while it would be out of 
> scope for JSR166, a reasonable path to solution might be to 
> introduce a new variant AccessController.doPrivileged method, say
>   doPrivileged(PrivilegedAction action, Thread context)
> With the requirement(?) that the context thread is no longer alive.
> This would act like the current doPrivileged, except that it 
> uses not only the supplied ACC (of the thread), but also 
> ITLs, priorities, etc. Doing it this way would reduce 
> pressure to define a explicit ThreadContext class. A 
> non-running thread used only for its context would not need 
> to occupy noticeably more resources than would a 
> ThreadContext object.  This would also evade the issue of 
> exactly what should be in a ThreadContext class.  This seems 
> promising to me, in part because it places the security 
> issues in AccessController, where they belong. Unfortunately 
> for the short term. we in JSR166 can't do anything along these lines.

Well, unfortunately this would still be pretty useless in the
applications of the sort I am developing, since they need to propagate
properties of alive threads. If you relaxed it to allow threads which
are not _yet_ alive, it would work: I could create a new child thread,
do not start it, and use it as a thread context, thus propagating
inheritable locals of the original, still alive thread. But then it
would be prone to races when the thread is started asynchronously (which
possibly could be prevented by doing extra locking between
AccessController and Thread classes). Either way it would be a rather
nasty hack (I appreciate now how you are sympathetic about the problem
if you're suggesting things like that :) I mean, requirement to give a
dead thread as an argument is rather odd from the API user point of
view. Well, maybe the user-space workaround I am testing now will prove
to be sufficient, given that the use of InheritableThreadLocal subclass
is widely acceptable.

Having the ThreadContext as a kind of generalization of
AccessControlContext is an intruquing idea though. I hope we will come
back to this at appropriate time.

Kind regards to everybody,
Dawid Kurzyniec