hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu
wash_ has quit [Read error: Connection reset by peer]
wash_ has joined #ste||ar
Yorlik has quit [Ping timeout: 252 seconds]
wash_ has quit [Ping timeout: 252 seconds]
wash_ has joined #ste||ar
hkaiser has joined #ste||ar
Yorlik has joined #ste||ar
Yorlik has quit [Ping timeout: 245 seconds]
K-ballo has joined #ste||ar
Yorlik has joined #ste||ar
FunMiles has joined #ste||ar
<FunMiles>
I was reading some OpenMPI documentation, looking for tasks, and the next paragraph I saw was that OpenMPI has changed the ownership of locks from thread to task. It made me think that std::mutex is owned by a thread. So I presume that HPX's mutexes are owned by the task and should be used where a mutex is used within a task? Also it seems that std::mutex would be deadly if used within HPX threads, since they can jum
<FunMiles>
p between OS threads.
<FunMiles>
Is that right?
<hkaiser>
FunMiles: yes
<hkaiser>
FunMiles: std::mutex is not good as it may block progress on the std thread that is used to run hpx tasks
<PatrickDiehl[m]>
FunMiles:
<PatrickDiehl[m]>
FunMiles:
<FunMiles>
hkaiser: I've also noticed that on my Mac with clang++ at least, if you try to unlock a std::mutex from another thread, it throws an exception or simply crashes. It's been a while, so I don't remember which, but it is a big no-no.
<hkaiser>
FunMiles: yes, you shouldn't do that
<hkaiser>
however, tasks will not move to a different thread if locked using std::mutex
<hkaiser>
they might move to a different thread if locked using hpx::mutex, though
<FunMiles>
Let me see if I understand correctly. Let's say I have: { std::mutex mtx; std::lock_guard lg{mtx}; hpx::async(some_task); std::cout <<"Releasing mutex"<< std::endl; } You are saying that during the call to hpx::async, the thread will not be moved? But if I have hpx::mutex mtx; then, it may be moved?
<FunMiles>
It's not that I would use that :) Now I will definitely be careful to use hpx::mutex, but it would mean that if for some reason, I interface with a library over which I have not control, and that library has a call back mechanism and they have a std::mutex around the call-back, the code is still safe.
<hkaiser>
FunMiles: ahh, you're right
<hkaiser>
FunMiles: what I meant was that while suspension when waiting to acquire the std::mutex the task will not be moved
<hkaiser>
you have a point - interfacing with traditional code is one of the weak points of HPX
<hkaiser>
you have to be very careful
<hkaiser>
but if you call external code that uses a std::mutex (or a pthread_mutex) then the only thing that could go wrong is that the whole HPX progress will be blocked on this thread/core while that mutex is being acquired
<FunMiles>
hkaiser: tricky possibility I came up with :) Now I understand what you meant.