Passing tokens between threads

[David Holmes]

Hi Tony,

In such a situation the "job" or "request" is what identifies the 
relationship - it defines the "context". So as you pass this "context" 
between threads, the code that processes it needs to setup/tear-down the 
association. Eg whatever Runnable/Callable is submitted to the 
threadpool needs to do something to set up the association; or the run() 
method of the thread you explicitly create and start, needs to set up 
the association.

The only other way to pass context like this around is to make every 
Class involved context-aware, and the context is then a part of every 
method call. But that would require creating your own threadpools etc - 
it's easier to run custom code in a standard pool than write a custom pool.

HTH

David

Tony Guan said the following on 05/07/10 08:04:
> Hi David,
> 
> Sorry, it was my bad, I should have given an example for the problem:
> 
> Let's Imagine thread A is monitoring one port at the server's side,
> when an incoming service request comes, thread A might spawn a new
> thread (B) to serve this particular request. But thread A could create
> a new Thread object or thread A just notify some mutex to let an
> existing thread(may from the thread pool) to do the job. And this
> thread B might in turn start other threads to finish its task, let's
> say, thread C,D,E.
> 
> I want to cluster thread B through thread E for their belonging to one
> common service request. But my problem now is, I don't have a way
> (even not good) to identify such relationship between them.
> 
> Since for one thread to trigger another one, can be a direct
> Thread.start() call, or just an Object.notifyAll() call.
> 
> For the Thread.start() call, it's easy, since we can put a field in
> the JavaThread to store its parent.
> 
> But for the Object.notifyAll(), it's too complicated, I don't have a
> way to trace the data flow to see if one thread will eventually arouse
> the execution of another one.
> 
> Any idea about my problem?
> 
> Thanks!
> 
> 
> Tony (Xiaohua Guan)
> 
> 
> 
> 
> On Thu, May 6, 2010 at 3:31 PM, David Holmes <David.Holmes at oracle.com> wrote:
>> Sorry Tony but I still don't know what you are trying to do. What is
>> "co-relate"? What "thread triggering relationship" do you mean?
>>
>> If you want to specialize allocation based on the thread then add a new
>> field to the JavaThread class in the VM (or higher up if needed).
>>
>> David
>>
>> Tony Guan said the following on 05/07/10 04:59:
>>> Hi David,
>>>
>>> Thanks for the reply.
>>>
>>> Actually, my aim is to manipulate the mutator threads inside the VM,
>>> because my project is to cluster some threads together, to allocate
>>> the objects from the same group(not the ThreadGroup) in certain area
>>> of the heap.
>>>
>>> Inside the VM, I don't quite know how to co-relate two thread together
>>> based on the thread triggering relationship.  This is what I am trying
>>> to figure out.
>>>
>>> Thanks again!
>>>
>>>
>>>
>>> Tony (Xiaohua Guan)
>>>
>>>
>>>
>>> On Wed, May 5, 2010 at 8:28 PM, David Holmes <David.Holmes at oracle.com>
>>> wrote:
>>>> Tony,
>>>>
>>>> Tony Guan said the following on 05/05/10 02:03:
>>>>> In my current project, I need to be able to pass tokens between
>>>>> certain threads inside VM. While it's easy when Thread A is directly
>>>>> calling the Thread B's start().
>>>>>
>>>>> But usually, the thread B is not directly created and started by
>>>>> thread A, for example, thread pooling. In this case, if I need to pass
>>>>> a token from thread A to thread B(which is triggered by A), I guess I
>>>>> will need to monitor the object that B is waiting on.
>>>>>
>>>>> While I am still pondering over this, is there any other advice?
>>>> I don't quite understand what you are asking. In shared-memory
>>>> multi-threading the primary communication path between threads is
>>>> shared-memory. So passing a "token" is a matter of writing some data into
>>>> a
>>>> memory location known to both threads. Then it is just a matter of how
>>>> much
>>>> encapsulation/abstraction you want to put around that memory location.
>>>>
>>>> David Holmes
>>>>