WHAT: Begin the process of introducing threads and thread safety into ORTE
WHY: ORTE is becoming increasingly dependent on thread-safe operations
(lock, cond_wait, unlock). However, OPAL thread support is defined to no-ops
unless --enable-opal-multi-threads is set. We need an independent way
of ensuring thread-safety in ORTE is active as doing so at the OPAL level
negatively impacts the MPI layer.
WHERE: Solely inside the ORTE code tree.
WHEN: No real rush - somewhere in the 1.5 series
TIMEOUT: Aug 13
----------------------------------------------------------------------------
Steps to be completed for Stage 1:
1. copy the opal thread code into a new orte/threads directory, renaming and editing as required
2. create ORTE_THREAD_[UN]LOCK macros that are always defined and active. Since ORTE isn't a performance-critical code path, we will always lock/unlock as required to protect global data (should help resolve some of our lingering thread-related problems). We will do a global search/replace for the OPAL macros inside the ORTE code tree and replace them with the new ORTE equivalents.
3. repackage the orte_job_data, orte_node_pool, orte_nidmap, and orte_jobmap global arrays into a new wrapper class that includes ORTE thread-locking support plus a pointer array. This will allow ORTE to thread-safe these values independent of whether or not OPAL threads are enabled.
4. add thread-lock/release code around areas where the globals in #3 are used.
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}