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 Fri, 02 Feb 2007 13:13:04 GMT
Angela Lin wrote:
>> > >                    45 hythread_tls_alloc
>> > >                    48 hythread_tls_get
>> > >                    49 hythread_tls_set
>> > >                    47 hythread_tls_free
> As long as you don't share TLS data between the VM and the portlib, it
> doesn't matter whether the portlib uses hythr's TLS API.

Agreed.

>> > >                    20 hythread_monitor_destroy
>> > >                    28 hythread_monitor_init_with_name
>> > >                    21 hythread_monitor_enter
>> > >                    23 hythread_monitor_exit
>> > >                    2B hythread_monitor_notify_all
>> > >                    32 hythread_monitor_wait
> I encourage you to continue to use these hythr functions for
> consistency of behaviour and compatibility with VM instrumentation, as
> discussed previously.

Looking at the portlibrary code, I've found 3 use cases of monitors:
a) mutex for NLS data -- this can be safely refactored to OS mutexes

b) global monitor to protect signal initialization -- this *needs* to use OS
mutexes if the thread library is loaded after port library. Besides, if the
port library is loaded before thread library, port library can't rely on thread
library to provide a process-wide globals.

c) wait-notify interaction of signal handler modification routines and signal
handlers themselves. This looks like a place where using thread library may be
preferrable over using OS condition variables directly.
BTW, what are the particular advantages of having asynchronous signal reporter
thread being managed by thread library?

Speaking of a asynchronous signal reporter thread, hythread_create() is an
additional dependency of libhyprt.so on libhythr.so, present only on Linux.
In order to use thread library monitors in this thread, it needs to be created
by the thread library or attached to the thread library, however, this thread
is also created at the port library initialization stage, when no thread
library is present yet.

The solution I see is to use OS condition variables and native thread creation,
but this makes signal reporter thread invisible to VM threading library and
thus invisible to JVMTI agents etc.

>> > >                     4 hythread_attach
> This is mandatory if you use hythr from any non-hythr-created thread,
> such as the main thread.
> 
>> > >                     9 hythread_detach
>> > >                    40 hythread_self
> These should be included if hythread_attach() is included.

Agreed.
Note, that hythread_self() is currently only used as a parameter to
hythread_tls_set/get, so it has no direct users, and can be eliminated
together with tls functions.

>> > >                    14 hythread_global
> In general, this function is used to set/get threadlib-wide settings
> (like a process-wide global variable). The VM often uses
> hythread_global() to pass configuration settings to hythr, such as
> when the command-line arguments are parsed.

In case threading library is provided by the VM, it becomes somewhat dubious
to depend on it for process-global variables. I think that assumption
that hyprt.dll is a single instance library is equally feasible.


> Specifically re: the "one big lock"
> (hythread_global("global_monitor")), the big lock is used to enforce
> process-wide serialization, which is useful for stuff like
> initialization and shutdown in a multiple-vm-per-process environment.
> I would be very careful about changing this.

The problem with "one big lock" being provided by thread library is that it is
needed at the port library initialization stage, when the thread library may
not be present yet.
-- 
Salikh Zakirov


Mime
View raw message