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][classlib] thread library - let there be one!
Date Tue, 24 Oct 2006 11:32:59 GMT
On 10/23/06, Angela Lin <alin.harmony@gmail.com> wrote:
>
> What is the goal here?
>
> 1. If the goal is to create a single thread library that can be used
> by multiple VM and classlib implementations, then the unified thread
> lib should contain everything needed to support a VM implementation.
>
> 2. If the goal is to simply define the interface between the classlib
> and the VM, then the 3rd option may be acceptable. This option seems
> to imply splitting up functionality that requires deep knowledge of
> the threading implementation, which I don't like. Each VM
> implementation would need to implement both the VM and classlib sides
> of the API.

Is this really the situation?  If Classlib only needs monenter/exit, TLS and
thread_create(), the "deep knowledge" required is probably only
monitorenter/exit which seems like a managable situation.


Regards,
> Angela
>
> On 10/19/06, Artem Aliev <artem.aliev@gmail.com> wrote:
> > Angela, all,
> >
> > I see you point and agree.
> > But if we move hythread lib to the VM we will require all VMs fully
> support it.
> > Is it necessary dependency?
> >
> > So Here is the third way I see.
> > Leave the minimum implementation of hythread in the classlib, with the
> > set of functions any VM should provide for classlib.
> >   This will simplifies adopting classlib to new VM and allows to have
> > solid threading model.
> > So any VM could have its own super set of threading functions.
> >
> > Note: Classlib uses only monitor, TLS, and thread_create() from
> hythread.
> >
> > Thanks
> > Artem
> >
> >
> >
> >
> > On 10/18/06, Angela Lin <alin.harmony@gmail.com> wrote:
> > > Artem et al,
> > >
> > > Sorry for jumping in late here.
> > >
> > > I maintain the J9VM thread lib.
> > >
> > > Option 1 worries me because it implies that the classlib could use a
> > > different threading model from the VM. This is bad because they both
> > > operate on the same threads.
> > >
> > > For example: Layer (2) of hythread might include internal thread state
> > > tracking, which is needed to support inspecting the thread state.
> > > Using layer (1) directly would bypass the thread state tracking.
> > >
> > > Angela
> > >
>

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