hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
<ste||ar-github>
hpx/function-storage 9732850 Agustin K-ballo Berge: Reuse function storage
ste||ar-github has left #ste||ar [#ste||ar]
Vir has joined #ste||ar
diehlpk_mobile has joined #ste||ar
diehlpk_mobile has quit [Ping timeout: 276 seconds]
__ASamir__ has joined #ste||ar
<__ASamir__>
Hello guys, I have a question regarding the mutex and the scheduling. Anybody can help?
<zao>
I probably can't, but I'd recommend asking your question :)
<zao>
If you hang around, chances are that it'll get answered.
<__ASamir__>
OK :) so, with the normal mutex when processes try to acquire a locked mutex, they are blocked and when the lock is released the scheduler unblocks the first waiting process from the queue. This is the normal situation. But here in HPX how is that handled? How is the distributed scheduler is implemented and how does it deal with mutex locks?
<zao>
Whenever you block on a HPX primitive that's not ready, the scheduler will be involved and run something that's ready.
<zao>
Mechanically, it swaps out the running state of the thread-of-execution, as each task has its own wee little stack and context.
<zao>
Control will return to the original HPX task when it's readied at some time in the future.
<zao>
Important for all this to work is that you don't use OS thread primitives like mutexes, as they'll block the whole OS thread-of-execution, preventing any HPX progress to be made in that particular one.
<zao>
Does this make sense?
<zao>
(some of the above may be a bit wrong, I haven't used HPX much)
<__ASamir__>
Does the mutex works only with the OS threads?
<__ASamir__>
It doesn't work with hpx threads?
<__ASamir__>
As far as I know is that there is a scheduling on the level of the hpx threads. so that if one hpx thread is blocked, the OS thread is not blocked
<zao>
HPX tasks are scheduled co-operatively whenever they would block.
<zao>
HPX has a bunch of OS threads that it runs HPX tasks on, and it's important to keep those threads from blocking on non-HPX functions.
<zao>
An OS mutex would "work" inside a HPX task, but it would completely halt any HPX progress on that thread and prevent that task from being scheduled anywhere else.