Talking about thread support ... i made a RFC several monthes ago in order to remove the --with-threads option from configure
/* ompi requires pthreads, no more, no less */ it was accepted, but i could not find the time to implement it ... basically, i can see three steps : 1) remove the --with-threads option from configure, check for pthreads, and set the OPAL_HAVE_POSIX_THREADS macro to 1 2) step 1) + remove #ifdef OPAL_HAVE_POSIX_THREADS and remove dead code (e.g. #ifndef OPAL_HAVE_POSIX_THREADS) 3) step 1) + step 2) + remove the OPAL thread abstraction layer is it a good idea to implement steps 2) and 3) ? i mean, if there is a chance we might support an other threading model in the future, it might be better to keep some dead code for the time being. any thoughts ? Cheers, Gilles On 2015/01/07 8:16, George Bosilca wrote: > On Tue, Jan 6, 2015 at 4:25 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> > wrote: > >> My enthusiasm for this was primarily because I thought we had talked about >> exactly this issue before (at the last meeting in Chicago?), and decided >> that the option is useless -- in part, because it always *must* be enabled >> for shared memory correctness. >> >> Is that incorrect? >> > This is correct. We need the memory fences and atomic operations for shared > memory in all cases. When thread support is enabled we also need them in > various other places. However, this option also turns on the lock prefix > for the atomic operations, forcing them to always be atomic. I am not sure > that this has no unexpected side-effects on the code. > > George. > > > >> >> On Jan 6, 2015, at 4:12 PM, George Bosilca <bosi...@icl.utk.edu> wrote: >> >>> Successive alteration of the build system made this option less relevant >> and especially less meaningful. However, while removing it sounds like a >> desirable cleanup, we have to keep in mind that this will enable all locks >> and all memory barriers even in cases where they are not necessary (via >> OPAL_WANT_SMP_LOCKS). >>> Thus, I do not share the enthusiasm of the others. I would prefer to see >> an evaluation of the impact on performance, a patch and a little bit more >> than 1/2 a day to react to it (the proposed deadline seems to be today >> January 6th) before such a drastic change. >>> George. >>> >>> >>> On Tue, Jan 6, 2015 at 12:05 PM, Ralph Castain <r...@open-mpi.org> wrote: >>> +1 >>> >>>> On Jan 6, 2015, at 9:04 AM, Jeff Squyres (jsquyres) < >> jsquy...@cisco.com> wrote: >>>> +1 >>>> >>>> On Jan 6, 2015, at 11:55 AM, Howard Pritchard <hpprit...@gmail.com> >> wrote: >>>>> I agree. Please remove this config option. >>>>> >>>>> 2015-01-06 9:44 GMT-07:00 Nathan Hjelm <hje...@lanl.gov>: >>>>> >>>>> What: Remove the --disable-smp-locks configure option from master. >>>>> >>>>> Why: Use of this option produces incorrect results/undefined behavior >>>>> when any shared memory BTL is in use. Since BTL usage is enabled even >>>>> when using cm for point-to-point this option can never be safely used. >>>>> >>>>> When: Thurs, Jan 6, 2015 >>>>> >>>>> -Nathan >>>>> >>>>> _______________________________________________ >>>>> devel mailing list >>>>> de...@open-mpi.org >>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >>>>> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2015/01/16736.php >>>>> _______________________________________________ >>>>> devel mailing list >>>>> de...@open-mpi.org >>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >>>>> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2015/01/16737.php >>>> >>>> -- >>>> Jeff Squyres >>>> jsquy...@cisco.com >>>> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>> _______________________________________________ >>>> devel mailing list >>>> de...@open-mpi.org >>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >>>> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2015/01/16739.php >>> _______________________________________________ >>> devel mailing list >>> de...@open-mpi.org >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2015/01/16740.php >>> _______________________________________________ >>> devel mailing list >>> de...@open-mpi.org >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2015/01/16741.php >> >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2015/01/16742.php >> > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2015/01/16743.php
