Announce: just::thread C++0x thread library beta 0.2
Anthony Williams
I am pleased to announce the release of the 0.2 beta release of the
just::thread C++0x thread library from Just Software Solutions Ltd.
The just::thread library is available from http://www.stdthread.co.uk
and provides an almost complete implementation of the thread library
from the C++0x working draft
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf.
Features include:
* Special deadlock-detection debug mode.
* Atomic types and operations: std::atomic_int, std::atomic<>, etc.
* Thread launching with std::thread.
* Mutexes and condition variables.
* One-time initialization with std::call_once.
* Promises, packaged tasks and futures for ease of transferring
results of operations between threads.
* Support for the new std::chrono time interface.
The library currently only works with Microsoft Visual C++ 2008
(including the Express edition), but support for other compilers and
platforms is in the pipeline.
To download the beta, sign up for the support forum at
http://www.stdthread.co.uk/forum/
All feedback gratefully received.
Anthony
--
Anthony Williams | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Chris M. Thomasson
news:uzlkux...@gmail.com...
> Hi,
>
> I am pleased to announce the release of the 0.2 beta release of the
> just::thread C++0x thread library from Just Software Solutions Ltd.
Cool. I downloaded it and intend to play around with it for sure... However,
I have one question; how are you implementing your mutex? I know I am
missing something obvious here!! But it kind of "seems" to use some overly
complicated logic <include/jss/mutex.hpp>. Humm... Wouldn't the Terekhov
Win32 mutex be simpler?
<quick sketch; watch for typos!>
_________________________________________________________________________
class mutex {
enum state {
UNLOCKED = 0, LOCKED = 1, CONTENTION = 2
};
atomic_word m_state; // = UNLOCKED
bin_sema m_wset; // binary semaphore set to false
public:
void lock() {
if (XCHG(&m_state, LOCKED)) {
while (XCHG(&m_state, CONTENTION)) {
m_wset.wait();
}
}
MEMBAR #StoreLoad | #StoreStore;
}
bool timed_lock(unsigned milliseconds) {
if (XCHG(&m_state, LOCKED)) {
bool adjust = false;
while (XCHG(&m_state, CONTENTION)) {
if (adjust) {
// dec milliseconds for elapsed time
} else {
adjust = true;
}
if (! m_wset.timed_wait(milliseconds)) {
return false;
}
}
}
MEMBAR #StoreLoad | #StoreStore;
return true;
}
bool try_lock() {
if (! CAS(&m_state, UNLOCKED, LOCKED)) {
return false;
}
MEMBAR #StoreLoad | #StoreStore;
return true;
}
void unlock() {
MEMBAR #LoadStore | #StoreStore;
if (XCHG(&m_state, UNLOCKED) == CONTENTION)) {
m_wset.set();
}
}
};
_________________________________________________________________________
AFAICT, that is kind of hard to beat on Windows... Also, I like the fact
that the fast-paths can be wait-free on the lock/timed_lock/unlock
functions... Have you benchmarked your impl against Terekhov's algorithm? I
am under the impression that if your on a platform that does not have
futexs, but does have bin-sema, then this algorithm works well.
What am I missing Anthony?
BTW, good work on your library! Thank you for creating it.
:^D
Anthony Williams
> "Anthony Williams" <antho...@gmail.com> wrote in message
> news:uzlkux...@gmail.com...
>> Hi,
>>
>> I am pleased to announce the release of the 0.2 beta release of the
>> just::thread C++0x thread library from Just Software Solutions Ltd.
> [...]
>
> Cool. I downloaded it and intend to play around with it for
> sure... However, I have one question; how are you implementing your
> mutex? I know I am missing something obvious here!! But it kind of
> "seems" to use some overly complicated logic
> <include/jss/mutex.hpp>. Humm... Wouldn't the Terekhov Win32 mutex be
> simpler?
Yes, it would be simpler, but I don't like it for reasons already
discussed on this list. I'm using the same algorithm I used for
Boost.Thread, which uses BTS for try_lock and the lock fast path, and
then CMPXCHG for the loop.
> AFAICT, that is kind of hard to beat on Windows... Also, I like the
> fact that the fast-paths can be wait-free on the
> lock/timed_lock/unlock functions... Have you benchmarked your impl
> against Terekhov's algorithm? I am under the impression that if your
> on a platform that does not have futexs, but does have bin-sema, then
> this algorithm works well.
>
> What am I missing Anthony?
The fast path is wait free on my algorithm too. LOCK BTS on
lock/try_lock, LOCK XADD on unlock. If there's contention, more
operations are required.
I did benchmark it against the Terekhov algorithm whilst I was
developing it for boost::mutex. IIRC, there was little difference. By
all means, run another benchmark.
My implementation also lazy-allocates the event, and only calls
SetEvent in unlock if required. This means that an uncontended mutex
never actually allocates an Event object, and it is safe for static
initialization. In an optimized build with MSVC 2008, a global
std::mutex object is statically initialized with my library. Sadly, if
you turn optimization down too low it doesn't look into the
constructor to inline it as static initialization.
> BTW, good work on your library! Thank you for creating it.
Cheers.
Chris M. Thomasson
> "Chris M. Thomasson" <n...@spam.invalid> writes:
>
>> "Anthony Williams" <antho...@gmail.com> wrote in message
>> news:uzlkux...@gmail.com...
>>> Hi,
>>>
>>> I am pleased to announce the release of the 0.2 beta release of the
>>> just::thread C++0x thread library from Just Software Solutions Ltd.
>> [...]
>>
>> Cool. I downloaded it and intend to play around with it for
>> sure... However, I have one question; how are you implementing your
>> mutex? I know I am missing something obvious here!! But it kind of
>> "seems" to use some overly complicated logic
>> <include/jss/mutex.hpp>. Humm... Wouldn't the Terekhov Win32 mutex be
>> simpler?
>
> Yes, it would be simpler, but I don't like it for reasons already
> discussed on this list.
[...]
I see. Correct me if I am wrong, but you don't seem to like the fact that
Alexs algorithm signals the wait when it clearly does not have to; right?
Humm... Well, IMVHO, it does not seem to be all that bad. Its definitely
inefficient when a previous waiter unlocks, but contention on a mutex should
be avoided by application anyway... Ahhh, wishful thinking. Anyway, I think
its nice that you get around that. For some reason, your solution with BTS
reminds me of using it in the fast-path with a futex taking care of the
slow-path. As you know, Alex Terekhov has given several examples of this
moment.
>> BTW, good work on your library! Thank you for creating it.
>
> Cheers.
Cheers Sir! Thank you.
:^D
Dmitriy V'jukov
> Hi,
>
> I am pleased to announce the release of the 0.2 beta release of the
> just::thread C++0x thread library from Just Software Solutions Ltd.
>
> The just::thread library is available from http://www.stdthread.co.uk
> and provides an almost complete implementation of the thread library
> from the C++0x working draft
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf.
What is the purpose of this library? Is it intended that I will just
replace "just::" with "std::" in future and throw away the library?
Dmitriy V'jukov
Dmitriy V'jukov
> The library currently only works with Microsoft Visual C++ 2008
> (including the Express edition), but support for other compilers and
> platforms is in the pipeline.
I am curious, how are you going to implement memory_order_consume on
platforms where acquire fence is not free?
Dmitriy V'jukov
Anthony Williams
"just::thread" is just the name of the library. If you use it, you can
write "std::thread" in the code. It *is* an implementation of the
C++0x thread library. You will never need to "throw it away" unless
you use a compiler that isn't supported.
Anthony
--
Anthony Williams
Author of C++ Concurrency in Action | http://www.manning.com/williams
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Just Software Solutions Ltd, Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK
Anthony Williams
Without compiler support, it will have to be an acquire fence.
Anthony
--
Anthony Williams
Author of C++ Concurrency in Action | http://www.manning.com/williams
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Just Software Solutions Ltd, Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK
Dmitriy V'jukov
> "Dmitriy V'jukov" <dvyu...@gmail.com> writes:
> > On 24 окт, 15:46, Anthony Williams <anthony....@gmail.com> wrote:
>
> >> The library currently only works with Microsoft Visual C++ 2008
> >> (including the Express edition), but support for other compilers and
> >> platforms is in the pipeline.
>
> > I am curious, how are you going to implement memory_order_consume on
> > platforms where acquire fence is not free?
>
> Without compiler support, it will have to be an acquire fence.
What do you think about following implementation:
T load_consume(T const* a)
{
T v = *const_cast<T const volatile*>(a);
acquire_compiler_fence();
return v;
}
?
It can break stupid things like:
int x = load_consume(y);
int z = q[x - x];
But must work for *real* data-dependencies.
Dmitriy V'jukov
Anthony Williams
> On 29 окт, 13:54, Anthony Williams <anthony....@gmail.com> wrote:
>> "Dmitriy V'jukov" <dvyu...@gmail.com> writes:
>> > On 24 окт, 15:46, Anthony Williams <anthony....@gmail.com> wrote:
>>
>> >> The library currently only works with Microsoft Visual C++ 2008
>> >> (including the Express edition), but support for other compilers and
>> >> platforms is in the pipeline.
>>
>> > I am curious, how are you going to implement memory_order_consume on
>> > platforms where acquire fence is not free?
>>
>> Without compiler support, it will have to be an acquire fence.
>
> What do you think about following implementation:
>
> T load_consume(T const* a)
> {
> T v = *const_cast<T const volatile*>(a);
Is that supposed to be "load relaxed"?
> acquire_compiler_fence();
> return v;
> }
> ?
>
> It can break stupid things like:
> int x = load_consume(y);
> int z = q[x - x];
>
> But must work for *real* data-dependencies.
I don't think so. If you load a pointer you still cannot safely
dereference it because the compiler fence won't force the ordering. Of
course, when it comes to a particular platform/compiler combination
you may be right --- as I port things to other platforms I will find
out.
Dmitriy V'jukov
Yes-yes, I meant hardware platforms which respect data-dependencies
(all alive platforms?).
Dereferencing of pointer (loaded with relaxed load) must be safe on
them.
Dmitriy V'jukov