just::thread V1.8.0 for Windows, Linux and MacOSX Released
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
int some_function();
std::shared_future<int> f(std::async(some_function)); // old syntax
auto f2=std::async(some_function).share(); // new syntax
Maybe. boost::thread_specific_ptr is slightly different again: though each pointer is freed automatically, you have to manually allocate and construct the object for each thread.It is, but at least it allows to have thread local objects and not to worry about freeing it up afterwards, which is simply impossible with __declspec(thread).
As far as I know boost::thread_specific is handled in special way in boost::thread calling procedure, so I can't use boost::thread_specific in std::thread, is it right?
Currently I'm using compilers support for TLS, but both GCC and MSVC have the same issue, they don't allow to have objects with non-trivial constructor in thread local storage, as far as I understood from C++ Concurrency in Action examples this is allowed in C++0x
maybe something like boost::thread_specific would be more useful here?
memory_order_acq_rel - which is again no-op on x86
Prevents compiler and hardware from reordering loads with load part of operation and stores with store part of operation.
Operation with memory_order_acq_rel flag means
atomic_thread_fence(memory_order_release);
operation();
atomic_thread_fence(memory_order_acquire);
Now, on page 18 of above mentioned article Bartosz says that Peterson Lock is an example of algorithm, which will not work without fences. However, Peterson's lock uses only acquire, release and acq-rel.
http://www.justsoftwaresolutions.co.uk/threading/petersons_lock_with_C++0x_atomics.html
If those operations are no-op on x86 then Peterson Lock has to work on x86 without any fence. Am I wrong somewhere?
For Dekker's algorithm it's clear, it uses sequentially consistent memory fence, so it requires fencing on x86 too, but what about Peterson lock?Quotethough such a fence can also be achieved with a LOCKed RMW instruction, such as XCHG.On Visual Studio MemoryBarrier() function is implemented as a not locked RMW instruction.
http://msdn.microsoft.com/en-us/library/ms684208(v=vs.85).aspxQuoteLONG Barrier;Is it a typeo in MSDN?
__asm {
xchg Barrier, eax
}
QuotePlain loads and stores on x86 give you acquire (for loads) and release (for stores) ordering. This is sufficient for many algorithms, but not for others. LFENCE and SFENCE are primarily of use with non-temporal stores such as MOVNTI, which don't obey the normal cache coherency rules (that's what "non-temporal" means, in effect --- they don't occur at a particular time).So it means that there is no analogs for sfence and lfence in C++1x, is it right?
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.Does it mean that fences are completely unneccessary on x86? In the article mentioned above I can see thisQuoteThere must be algorithms that require fences even on the x86.and there are mfence, sfence and lfence instructions available on x86. How does your library work if it doesn't use them and where they are used? Could you please explain this in more details?
It does help, thanks for replying
This issue of the non-copy mutex really interests me.
I can't help wondering why it is non-copyable.
Is this issue to do with whether the mutex would be a deep vs shallow copy of the mutex ?
What danger or mischief is prevented by making a mutex non-copyable ?
Java has a unique intrinsic lock built into every object of every class.
To the best of knowledge, there are no special hazards associated with this scenario.
(but of-course, i don't know, what i don't know)
consider this simple class (shown below)
It's just a callable functor class, implementing the func. call operator.
I find that when i declare a mutex inside this class, the compiler curses me...
.. uttering words like:
/usr/include/justthread/mutex: In copy constructor ‘functor::functor(const functor&)’:
threadId.cxx:19: instantiated from ‘__jss::__0x::__invoker<_ResultType, _Callable, _Args>::__invoker(_Callable&, const __jss::__0x::__args_tuple<_OtherArgs ...>&) [with _OtherArgs = , _ResultType = void, _Callable = functor&, _Args = ]’
When i make the mutex global (line 17).. the code compiles and runs as expected.
I also tried wrapping the mutex in a unique_lock. But ... no joy.
Is it not possible to define a mutex as a class member ?
Any suggestions.. warmly welcomedQuote
std::mutex is not copyable. That means that if you define a mutex as a class member then the compiler cannot implicitly define the copy constructor, and you get an error message like the one you show when you try and copy your class.
If you want to make your class copyable then you need to write a copy constructor that default-constructs the mutex. You might also want to lock the mutex on the source whilst you do the copy, so that you don't get a race condition.
However, if you are copying your functor onto a thread then you probably don't need a mutex, as the thread will be the only place that can access the copy that was running on the thread, so no synchronization is needed. The fact that you think you need synchronization suggests you intend to access the same object from multiple threads, in which case you probably want to pass the functor by reference using std::ref (or std::tr1::ref if std::ref is not available):Code: [Select]functor f;
std::thread t(std::ref(f));
Hope that helps,
Anthony
g++ -std=c++0x -pthread -I/usr/include/justthread -D_JUST_THREAD_DEADLOCK_CHECK -g -rdynamic -o sample_deadlockcheck sample_deadlock.cpp -ljustthread_check#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;
}