Recent Posts

Thank you Anthony, that did it 

I have updated the online documentation at http://www.stdthread.co.uk/doc/deadlockdebug.html

Oops. The documentation needs updating. 

You need to ensure that the just::thread headers are being used, and that the checked version of the library is being linked.

Code:

g++ -std=c++0x -pthread -I/usr/include/justthread -D_JUST_THREAD_DEADLOCK_CHECK -g -rdynamic -o sample_deadlockcheck sample_deadlock.cpp -ljustthread_check

If you don't link against the checked version of the library then you'll get linker errors if the include path is set up correctly.

Also, if you move the lock in main() to before the creation of the thread then you'll get a deadlock every time:

Code:

#include <thread>
#include <mutex>
#include <iostream>

std::mutex io_mutex;

void thread_func()
{
    std::lock_guard<std::mutex> lk(io_mutex);
    std::cout<<"Hello from thread_func"<<std::endl;
}

int main()
{
    std::lock_guard<std::mutex> lk(io_mutex);
    std::thread t(thread_func);
    std::cout<<"Hello from main thread"<<std::endl;
    t.join();
    return 0;
}

Hi,

I tried the deadlock detection sample in the documentation
I compiled as instructed
g++ -std=c++0x -pthread -D_JUST_THREAD_DEADLOCK_CHECK -g -rdynamic -o sample_deadlockcheck sample_deadlock.cpp -ljustthread -lrt

When running the program I do get the deadlock but I don't get the deadlock detection prinouts AND the app does not terminate (as it should with std::terminate), to make sure the standard error stream wasn't lost on me I called the sample like this
 ./sample_deadlockcheck  &>  log.out

I have not tested this on Windows yet, this was on Ubuntu

Best Regards
Kjell Hedström

And just for clarity: just::thread does not support g++ 4.5 or later in the current release.

The native gcc support in the current trunk for the library facilities such as futures is listed at http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.200x. For a particular version you'll have to check your local copy of that documentation page, as the gcc website doesn't seem to list the support that shipped with each individual version.

These two (gcc 4.5.1 &  4.6) are still having fits with futures/asyncs (bomb at runtime, 4.6 a bit more cleanly)
(local rebuild from sources on (uname -a):
Linux Gypsy-IV 2.6.32-25-server #43-Ubuntu SMP Wed Sep 1 10:54:43 UTC 2010 x86_64 GNU/Linux

Note futures are not even in the C++0x supported/unsupported list, see http://gcc.gnu.org/projects/cxx0x.html (concurrency?), does anyone know?

I am pleased to announce the release of V1.3 of just::thread for both Ubuntu Linux and Windows.

This release includes the following changes:

• Support for the new std::async function for launching asynchronous tasks with return values. This allows you to quickly and easily take advantage of the available hardware concurrency without excessive oversubscription.
• Support for the new std::atomic_future class template which allows a single reference to a shared future value to be updated from multiple threads.
• Support for 64-bit Windows has been added to the Portability Bundle
• The <cstdatomic> header has been renamed to <atomic>
• The std::unique_future class template has been renamed to std::future
• Plus various other small changes to bring the code into line with the current C++0x working draft

I was just reading slides from a talk that are available here:

http://www.nwcpp.org/Downloads/2008/Memory_Fences.pdf

On page 16, this person asserts that on x86, the memory model enables the relaxed std::atomic conditions shown on that slide to be implemented as nothing, so there would be no performance penalty for that code (assuming the atomic types had atomic store instructions), only that the compiler be required not to reverse the orders.

My questions:
1. Is this person correct?

Yes, plain loads have acquire semantics and plain stores have release semantics on x86. Note that actually, the ordering on the data variable are superfluous and could be replaced with std::memory_order_relaxed: the operations on ready are sufficient to guarantee the ordering.

2. Would your library for Visual Studio indeed implement as no-ops?

some_atomic.load(std::memory_order_acquire) does just drop through to a simple load instruction, and some_atomic.store(std::memory_order_release) drops through to a simple store instruction. However, this instruction is wrapped in compiler directives to ensure that the compiler doesn't reorder it in a way that could break the desired semantics.

3. How does your library force the compiler not to reorder the stores?

By using appropriate compiler directives in the code. For Visual Studio 2008, _ReadWriteBarrier is used.

Anthony

Hello,

I was just reading slides from a talk that are available here:

http://www.nwcpp.org/Downloads/2008/Memory_Fences.pdf

On page 16, this person asserts that on x86, the memory model enables the relaxed std::atomic conditions shown on that slide to be implemented as nothing, so there would be no performance penalty for that code (assuming the atomic types had atomic store instructions), only that the compiler be required not to reverse the orders.

My questions:
1. Is this person correct?
2. Would your library for Visual Studio indeed implement as no-ops?
3. How does your library force the compiler not to reorder the stores?

Thanks