harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm] thread local storage in open/hythread.h
Date Mon, 31 Mar 2008 15:47:21 GMT
On the 0x418 day of Apache Harmony Francis ANDRE wrote:
> zthread is a high level C++ thread abstraction package that provides almost
> the basic multi threading primitives like Semaphore, RWLock, RecursiveRWLock,
> Barrier, Condition, ThreadLocal support, etc... as well as high level
> primitive like Worker,
> ConcurrentQueues and so on...(similar to the concurrent package from Doug Lea)
> 
> IMHO, it is an high level, abstract, mostly complete and portable
> threading package in C++...

GPL

> Francis
> 
> Nathan Beyer a écrit :
> > On Mon, Mar 31, 2008 at 7:45 AM, Francis ANDRE <francis.andre@easynet.fr>
wrote:
> >>  >> Do you have any suggestions or preferences about a particular TLS
> >>   >> approach? I'm all for fast, but I tend to lean towards a consistent
> >>   >> (single) clean approach, even it it's not the fastest approach.
> >>
> >>  What would you think about using the zthread package as general rule and using
> >>  optimal hand coded part for optimization??
> >>  http://zthread.sourceforge.net/
> >>
> >>  Francis
> > I'm not familiar with that project, so I can't really comment. What
> > would be the advantages of using it?
> > -Nathan
> >
> >>  Pavel Rebriy a écrit :
> >>
> >>
> >>> Nathan,
> >>  >
> >>  > TLS access is a performance critical function, that why unified (single,
> >>  > clean) approach could have 20-30% of performance degradation on some
> >>  > benchmarks.
> >>  >
> >>  > On 31/03/2008, Nathan Beyer <nbeyer@gmail.com> wrote:
> >>  >> On Sun, Mar 30, 2008 at 4:41 PM, Gregory Shimansky
> >>  >> <gshimansky@apache.org> wrote:
> >>  >>> On 29 мара 2008 Nathan Beyer wrote:
> >>  >>>  > In open/hythread.h there is the following bit of code.
> >>  >>>  >
> >>  >>>  > #ifdef PLATFORM_POSIX
> >>  >>>  > extern __thread hythread_t tm_self_tls;
> >>  >>>  > #else
> >>  >>>  > extern __declspec(thread) hythread_t tm_self_tls;
> >>  >>>  > #endif //PLATFORM_POSIX
> >>  >>>  >
> >>  >>>  >
> >>  >>>  > hy_inline hythread_t VMCALL hythread_self() {
> >>  >>>  >     return tm_self_tls;
> >>  >>>  > }
> >>  >>>  >
> >>  >>>  > From what I know at the moment, the use of '__thread' isn't
a POSIX
> >>  >>>  > standard, but rather a gcc extension and '__declspec(thread)'
is a
> >>  >>>  > MSVC thing, so the check isn't quite correct. Neither of
these works
> >>  >>>  > on MacOS X and from what I've been able to gather, it shouldn't
work
> >>  >>>  > on FreeBSD, but I can't confirm that. In any case, I was
looking at
> >>  >>>  > implementing this for MacOSX and FreeBSD using pthread_key_t.
It
> >>  >> seems
> >>  >>>  > like that could be used for other (all?) platforms as well.
Any
> >>  >>>  > thoughts on that?
> >>  >>>
> >>  >>>  AFAIK there are plenty of different implementation for getting
TLS in
> >>  >> DRLVM's
> >>  >>>  implementation of hythread. There are fast ways like those you've
> >>  >> mentioned,
> >>  >>>  slow ways using APR and pthread and very fast ways using inline
> >>  >> assembly.
> >>  >>>  All of them are quite messed up right now and need some cleaning.
The
> >>  >> mess is
> >>  >>>  with different defines that rule the whole stuff - it is not
always
> >>  >> clear
> >>  >>>  which define set is used for a particular implementation on a
given
> >>  >> platform.
> >>  >>
> >>  >>
> >>  >> I would agree that the defines are a bit of a mess or at least seem
> >>  >> like it at times.
> >>  >>
> >>  >> Do you have any suggestions or preferences about a particular TLS
> >>  >> approach? I'm all for fast, but I tend to lean towards a consistent
> >>  >> (single) clean approach, even it it's not the fastest approach.
> >>  >>
> >>  >>>  --
> >>  >>>  Gregory
> >>  >>>
> >>  >
> >>  >
> >>  >
> >>
> 
> 

-- 
Egor Pasko


Mime
View raw message