harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [vmi] thread library
Date Tue, 30 Jan 2007 22:02:43 GMT
Ronald Servant wrote:
> I've opened H-3090 and attached a patch to it that would allow us to
> implement a threading API.
> I think the patch is complementary to Salikh's work on minimizing what
> would need to be provided in such an API.
> Let me know your thoughts.

I've copied part of your JIRA comment over here for discussion.

> One such issue would involve thread local storage (TLS). The Harmony
> implementation of TLS uses static variables as the basis for its
> implementation. Those statics are confined on a shared library basis.
> Meaning that if a TLS value was being set when the VM called a thread
> lib function, a call to a thread lib function from the classlib would
> not see that TLS data. This is due to the VM and classlib using
> different thread library shared libraries.

Is this a problem in practice?  Can you think of a case where the VM and
classlib exchange data through TLS like this?

> The thread library used by the VM, for example, could be relying on
> some storing values in TLS that will modify the behaviour of other
> calls to thread library functions. When the classlib calls it's own
> implementation of thread library functions, the behvaiour of those
> functions will not be modified by the values set in TLS by the VM.

Agreed, this says that a single, consistent threadlib is the answer --
and as we have discussed elsewhere the VM needs some control (or at
least oversight) of these calls for thread management etc.

> A solution to these problems would be to create a standard thread API,
> much like the one created for the port library.

and the API is likely reduced from the threadlib functions we have in
class library code today, to include just those that Salikh has listed.

> The VM would become responsible for providing the hythr shared library.
> The classlib (and other tools that use threading functions) would
> compile against the API and no-opt implementation of hythr.

Or we could provide a working reference impl of the functions for VMs
that don't care, and support testing the portlib without a VM present.

> The attached patch is one possible implementation of this idea. It
> creates a thread library table (HyThreadLibrary) much like the port
> library table. The thread library is created by the port library during
> the port library's initialization. The thread library can be obtained
> from the port library using the new port_get_thread_library() function.

I need to look at the patch to see how you did that, and also allow a VM
to provide the impl.

> Also, the VMI has been extended to include a new GetThreadLibrary()
> function. Alternatively, we could leave the VMI as is and modify the
> following defines in hythread.h to:
> #define THREAD_ACCESS_FROM_VMI(vmi) HyPortLibrary *privatePortLibraryForThread = (*vmi)->GetPortLibrary(vmi);
> HyThreadLibrary *privateThreadLibrary = privatePortLibraryForThread ->port_get_thread_library(privatePortLibraryForThread)
> THREAD_ACCESS_FROM_ENV and THREAD_ACCESS_FROM_JAVAVM would need to be modified in a similar

May as well modify the macros, I don't see a use for the
GetThreadLibrary() function directly.


View raw message