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++...
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
>>>
>
>
>
