Exists otherwise enters thread pool waicng for more

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: thread run some sort of “work manager” funcCon rather than a “task” –  e.g., “wait unCl a task becomes available… then run it” •  could implement using bounded buffers of tasks –  more complicated to code up + amorCzes overhead of creaCng/destroying threads CSEP 524: Parallel ComputaCon Winter 2013: Chamberlain 9 Tasks/Threads in Chapel •  Chapel has mulCple tasking layers –  Each has its own implementaCon and policies –  Default layer (CHPL_THREADS = “fifo”): •  program with 1 thread running main() •  new thread created for each new task… …unless a thread is silng around bored in the pool… see below …or there aren’t enough resources to create one …or we hit the user specified limit (numThreadsPerLocale) in which case, the task is put into a task pool for execuCon later •  each thread runs its task to compleCon –  task can also help with its cobegin/coforall tasks (“nothing else to do”) •  upon compleCon, runs an unclaimed task if one exists •  otherwise, enters thread pool waiCng for more tasks to show up CSEP 524: Parallel ComputaCon Winter 2013: Chamberlain 10 Tasks/Threads in Chapel •  Chapel has mulCple tasking layers –  each has its own implementaCon and policies –  Most other layers (qthreads, massivethreads, nanox) •  primarily uClize user- level lightweight threading •  create # pthreads equal to # cores (or user- specified value) •  each pthread mulCplexes between mulCple tasks –  typically switches on blocking events like sync var reads/writes –  someCmes switches on long- latency events like communicaCon –  Also a HW mulCthreading layer (mta) •  map each task to its own HW thread context (~128 per node) •  HW switches between tasks For more info: doc/README.tasks CSEP 524: Parallel ComputaCon Winter 2013: Chamberlain 11 Tasks/Threads and Virtualiza3on •  In any parallel programming environment, whenever # tasks > # cores, something must give –  OS can mulCplex between system- level threads –  runCme can mulCplex tasks/user- level threads over system threads –  tasks can stall and wait for resources to become available •  AqenCon to these issues can be crucial to obtaining top performance CSEP 524: Parallel ComputaCon Winter 2013: Chamberlain 12 How Many Tasks Should I Use? •  It depends... (on your algorithm and architecture) –  For many problems # tasks == # cores can...
View Full Document

Ask a homework question - tutors are online