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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > >> >> On Sun, Mar 30, 2008 at 4:41 PM, Gregory Shimansky > >> >> <[EMAIL PROTECTED]> 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
