harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Angela Lin" <alin.harm...@gmail.com>
Subject Re: [vmi] thread library
Date Wed, 31 Jan 2007 16:24:42 GMT
On 1/31/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> 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.
>
> Ron implies that there is data shared between the two.  Perhaps we
> provide for the opportunity to do so by providing these functions in the
> threadlib API, even if there is no such sharing taking place today.

My comments were focused on the portlib, not the classlib, and so I
didn't look at the classlib usage closely. I've grepped our codebase
and I don't see the classlib directly using this API.

Ron's comments, regarding this and MACRO_SELF()/hythread_self(),
pertain more appropriately to the problems with loading 2 distinct
thread libraries where only one is expected. i.e. You end up with two
copies of internal threadlib state that aren't synchronized which each
other.

> >> > >                    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.
>
> Yep, and one again I think it would be reasonable to provide a reference
> implementation / utility library that has the thin wrappers to the OS
> function for VMs that are happy to just pass through.
>
> >> > >                     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.
>
> All of attach, detach, and self would be required to be implemented by
> the VM.
>
> >> > >                    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.
>
> Do we only need this capability for the threadlib, how about the entire
> portlib?

I consider this nice to have, but not crucial.

There's a more generic problem of how (and when!) command line
arguments should be passed to the thread library. hythread_global()
addresses the how, but not the when.

>
> > 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.
>
> If there is some contract around honouring this monitor then it needs to
> be described.

Use the global monitor as a last resort to enforce process-wide
serialization, particularly to protect resources that may be accessed
by multiple VMs.

POSIX-style signal handlers are a process-wide resource, which is why
the port library holds the global monitor while installing them.

Angela

Mime
View raw message