harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][threading] synchronizing native and java access of the thread state (Harmony-3289)
Date Mon, 05 Mar 2007 04:04:00 GMT
On 3/4/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> If the thread states query and modification methods are mostly native,
> I think a native lock is more feasible. Then we don't need a special
> trick to stuff a java object with a "native" field.

hmm... my guess is that we still have the same problem which is the need to
query java  thread state from Java as well as from native code.  Note a java
app can keep a java.lang.Thread around even if the thread has exited.  And
it can query if this thread is still alive.  If the "isAlive" field is not
inside java.lang.Thread, then I guess it would have to be in struct HyThread
and somehow this struct would have to remain connected to the
java.lang.Thread as long as j.l.Thread is reachable from java code.

Btw, native methods, including JVMTI, can use native monitor APIs to
> access the Java object lock. But I would prefer native locking for
> threading operations.
> Thanks,
> xiaofeng
> On 3/5/07, Weldon Washburn <weldonwjw@gmail.com> wrote:
> > I decided to put a response to H3289 on the dev list since it is a
> general
> > threading issue.  Please look at 3289 for background info.
> >
> > In response to the question about JVMTI functions being able to grab a
> lock
> > in java.lang.Thread class, maybe a workable approach would be to replace
> > locking the java object with a mutex created in native code and stuffed
> into
> > a private int field of java.lang.Thread.  The Java code would
> use  native
> > method APIs to grab and release this new native mutex.   And the native
> code
> > (including JVMTI) would use the standard hymutex_lock(),
> hymutex_unlock().
> > The native code would manage the life-cycle of the private int field
> > containing a pointer to the native mutex.
> >
> >
> >
> > --
> > Weldon Washburn
> > Intel Enterprise Solutions Software Division
> >

Weldon Washburn
Intel Enterprise Solutions Software Division

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message