harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salikh Zakirov <Salikh.Zaki...@Intel.com>
Subject Re: [vmi] thread library
Date Tue, 30 Jan 2007 10:11:16 GMT
Tim Ellison wrote:
> ... there is a dependency on
> threadlib from the portlib, and the portlib functions don't get a
> reference that can reach 'back' to the VMI struct.
> So while it may be apparent in the launcher, it would be equally
> apparent in the portlib functions themselves, since they would have no
> reachable threadlib.
> So maybe, as you say, we need to make the threadlib functions an
> extension of the current portlib function table rather than the VMI
> struct, and have them provided by a DLL loaded by the VM (and the thread
> function table populated in the portlib initialization code).
> Any other options?

The list of dependencies of port library on thread library is as follows
(got from `dumpbin /imports hyprt.dll`)

                   48 hythread_tls_get
                   40 hythread_self
                   49 hythread_tls_set
                   47 hythread_tls_free
                   23 hythread_monitor_exit
                   2B hythread_monitor_notify_all
                   14 hythread_global
                   32 hythread_monitor_wait
                    4 hythread_attach
                    9 hythread_detach
                   20 hythread_monitor_destroy
                   28 hythread_monitor_init_with_name
                   21 hythread_monitor_enter
                   45 hythread_tls_alloc


* hythread_tls_get, hythread_tls_set, hythread_tls_free, hythread_tls_alloc,
hythread_self are used exclusively for TLS access, which can be provided by
thin OS-function wrappers independently of the threading library.

Attached patch is a dirty way to eliminate dependency,
intended as an illustration of how this can be done.

* hythread_global is used exclusively as hythread_global("global_monitor"),
with a purpose of having one big lock. I'm not exactly sure if it is relevant
that LUNI and ARCHIVE want to use the same global monitor. I suspect that this
is not really needed, and PORTLIB, ARCHIVE and LUNI can use different monitors.

* hythread_monitor_ functions provide native synchronization primitives, which
are not connected to java objects in any way, and are not exposed to the VM,
so these also can be implemented directly in portlib as thin OS-function wrappers.

* hythread_attach and hythread_detach -- these imply attaching thread to the
VM, and thus cannon be implemented without dependency on threading library.


it seems that the issue of making thread library completely VM-specific boils
down to finding a good way of attaching/detaching a thread to/from VM.

Currently, I'm not sure how can this be done, since the first time launcher
initializes the porting library, and port library calls hythread_attach(), is
even before launcher knows which VM it will use. Chicken-and-egg problem again.


View raw message