Re: [OMPI devel] pthreads (was: Re: RFC: remove --disable-smp-locks)

2015-01-16 Thread Gilles Gouaillardet 
Folks,

i pushed two commits in order to remove the --with-threads option and
the dead code :

commit 7a55d49ca78bcc157749c04027515f12b026ec33
Author: Gilles Gouaillardet 
List-Post: devel@lists.open-mpi.org
Date:   Tue Oct 21 19:13:19 2014 +0900

configury: per RFC, remove the --with-threads option


commit 661c35ca677512129cef9bca1bbbf5b5b71d951b
Author: Gilles Gouaillardet 
List-Post: devel@lists.open-mpi.org
Date:   Tue Oct 21 19:49:58 2014 +0900

cleanup dead code caused by the removal of the --with-threads
configure option


i did not remove the opal abstraction layer (e.g. opal_thread_t and
friends) since it
is not only an abstraction layer, but it brings additional features.

Cheers,

Gilles

On 2015/01/08 1:50, Ralph Castain wrote:
> See note on other thread as to why we made the pthread decision
>
>> On Jan 7, 2015, at 8:30 AM, Jeff Squyres (jsquyres)  
>> wrote:
>>
>> Ok.  Then I'm good with Gilles' plan.
>>
>> Anyone else?
>>
>>
>> On Jan 7, 2015, at 11:29 AM, Nathan Hjelm  wrote:
>>
>>> Yes, we decided some time back that pthreads is a minimum requirement
>>> for Open MPI.
>>>
>>> -Nathan
>>>
>>> On Wed, Jan 07, 2015 at 04:26:01PM +, Jeff Squyres (jsquyres) wrote:
 On Jan 7, 2015, at 11:22 AM, Gilles Gouaillardet 
  wrote:

> Valid options are :
> --with-threads e.g. --with-threads=posix e.g. default
> And
> --with-threads=no
>
> Except configure will explicitly fail if --with-threads=no is used
 Which is the moral equivalent of not having this option.  :-)  (which I 
 think is your point :-) )

> So bottom line, pthreads and pthreads only are usable
 But my question remains: we all decided that OMPI will *require* pthreads, 
 right?  (i.e., configure will fail if pthreads are not available)

 I am being pedantic here, I know -- but it's slightly different than what 
 you're saying, and this threading stuff is already quite confusing...


> Cheers,
>
> Gilles 
>
> "Jeff Squyres (jsquyres)" さんのメール:
>> On Jan 7, 2015, at 4:25 AM, Gilles Gouaillardet 
>>  wrote:
>>
>>> 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 */
>> Did we decide this?  (that OMPI *requires* pthreads)
>>
>> I *think* we did.  But I just want to make sure that my (terrible) 
>> memory is correct...
>>
>>> 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
>> Sounds good.
>>
>>> 2) step 1) + remove #ifdef OPAL_HAVE_POSIX_THREADS and remove dead code
>>> (e.g. #ifndef OPAL_HAVE_POSIX_THREADS)
>> Also make configure fail if pthreads are not available.
>>
>>> 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.
>> I think the consensus was that pthreads are fine for the foreseeable 
>> future.  If we need to re-add the threading abstraction layer, it's 
>> annoying, but not difficult.  Might as well simplify what we have, since 
>> there's no other threading system on the horizon that we need to worry 
>> about.
>>
>> -- 
>> 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/16750.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/16751.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:

Re: [OMPI devel] pthreads (was: Re: RFC: remove --disable-smp-locks)

2015-01-07 Thread Ralph Castain 

> On Jan 7, 2015, at 8:13 AM, Jeff Squyres (jsquyres)  
> wrote:
> 
> On Jan 7, 2015, at 4:25 AM, Gilles Gouaillardet 
>  wrote:
> 
>> 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 */
> 
> Did we decide this?  (that OMPI *requires* pthreads)
> 
> I *think* we did.  But I just want to make sure that my (terrible) memory is 
> correct…

I believe we did - at least, we require that libevent be thread-enabled, and 
that means it definitely requires pthreads. Since that component is statically 
built, that pull the pthread lib into the ompi lib anyway, so I see no problem 
in “requiring” it.

> 
>> 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
> 
> Sounds good.
> 
>> 2) step 1) + remove #ifdef OPAL_HAVE_POSIX_THREADS and remove dead code
>> (e.g. #ifndef OPAL_HAVE_POSIX_THREADS)
> 
> Also make configure fail if pthreads are not available.
> 
>> 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.
> 
> I think the consensus was that pthreads are fine for the foreseeable future.  
> If we need to re-add the threading abstraction layer, it's annoying, but not 
> difficult.  Might as well simplify what we have, since there's no other 
> threading system on the horizon that we need to worry about.
> 
> -- 
> 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/16750.php

Re: [OMPI devel] pthreads (was: Re: RFC: remove --disable-smp-locks)

2015-01-07 Thread Jeff Squyres (jsquyres) 
Ok.  Then I'm good with Gilles' plan.

Anyone else?


On Jan 7, 2015, at 11:29 AM, Nathan Hjelm  wrote:

> 
> Yes, we decided some time back that pthreads is a minimum requirement
> for Open MPI.
> 
> -Nathan
> 
> On Wed, Jan 07, 2015 at 04:26:01PM +, Jeff Squyres (jsquyres) wrote:
>> On Jan 7, 2015, at 11:22 AM, Gilles Gouaillardet 
>>  wrote:
>> 
>>> Valid options are :
>>> --with-threads e.g. --with-threads=posix e.g. default
>>> And
>>> --with-threads=no
>>> 
>>> Except configure will explicitly fail if --with-threads=no is used
>> 
>> Which is the moral equivalent of not having this option.  :-)  (which I 
>> think is your point :-) )
>> 
>>> So bottom line, pthreads and pthreads only are usable
>> 
>> But my question remains: we all decided that OMPI will *require* pthreads, 
>> right?  (i.e., configure will fail if pthreads are not available)
>> 
>> I am being pedantic here, I know -- but it's slightly different than what 
>> you're saying, and this threading stuff is already quite confusing...
>> 
>> 
>>> Cheers,
>>> 
>>> Gilles 
>>> 
>>> "Jeff Squyres (jsquyres)" さんのメール:
 On Jan 7, 2015, at 4:25 AM, Gilles Gouaillardet 
  wrote:
 
> 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 */
 
 Did we decide this?  (that OMPI *requires* pthreads)
 
 I *think* we did.  But I just want to make sure that my (terrible) memory 
 is correct...
 
> 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
 
 Sounds good.
 
> 2) step 1) + remove #ifdef OPAL_HAVE_POSIX_THREADS and remove dead code
> (e.g. #ifndef OPAL_HAVE_POSIX_THREADS)
 
 Also make configure fail if pthreads are not available.
 
> 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.
 
 I think the consensus was that pthreads are fine for the foreseeable 
 future.  If we need to re-add the threading abstraction layer, it's 
 annoying, but not difficult.  Might as well simplify what we have, since 
 there's no other threading system on the horizon that we need to worry 
 about.
 
 -- 
 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/16750.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/16751.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/16752.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/16753.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] pthreads (was: Re: RFC: remove --disable-smp-locks)

2015-01-07 Thread Nathan Hjelm 

Yes, we decided some time back that pthreads is a minimum requirement
for Open MPI.

-Nathan

On Wed, Jan 07, 2015 at 04:26:01PM +, Jeff Squyres (jsquyres) wrote:
> On Jan 7, 2015, at 11:22 AM, Gilles Gouaillardet 
>  wrote:
> 
> > Valid options are :
> > --with-threads e.g. --with-threads=posix e.g. default
> > And
> > --with-threads=no
> > 
> > Except configure will explicitly fail if --with-threads=no is used
> 
> Which is the moral equivalent of not having this option.  :-)  (which I think 
> is your point :-) )
> 
> > So bottom line, pthreads and pthreads only are usable
> 
> But my question remains: we all decided that OMPI will *require* pthreads, 
> right?  (i.e., configure will fail if pthreads are not available)
> 
> I am being pedantic here, I know -- but it's slightly different than what 
> you're saying, and this threading stuff is already quite confusing...
> 
> 
> > Cheers,
> > 
> > Gilles 
> > 
> > "Jeff Squyres (jsquyres)" さんのメール:
> >> On Jan 7, 2015, at 4:25 AM, Gilles Gouaillardet 
> >>  wrote:
> >> 
> >>> 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 */
> >> 
> >> Did we decide this?  (that OMPI *requires* pthreads)
> >> 
> >> I *think* we did.  But I just want to make sure that my (terrible) memory 
> >> is correct...
> >> 
> >>> 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
> >> 
> >> Sounds good.
> >> 
> >>> 2) step 1) + remove #ifdef OPAL_HAVE_POSIX_THREADS and remove dead code
> >>> (e.g. #ifndef OPAL_HAVE_POSIX_THREADS)
> >> 
> >> Also make configure fail if pthreads are not available.
> >> 
> >>> 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.
> >> 
> >> I think the consensus was that pthreads are fine for the foreseeable 
> >> future.  If we need to re-add the threading abstraction layer, it's 
> >> annoying, but not difficult.  Might as well simplify what we have, since 
> >> there's no other threading system on the horizon that we need to worry 
> >> about.
> >> 
> >> -- 
> >> 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/16750.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/16751.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/16752.php


pgp6ohjPwejs2.pgp
Description: PGP signature

Re: [OMPI devel] pthreads (was: Re: RFC: remove --disable-smp-locks)

2015-01-07 Thread Jeff Squyres (jsquyres) 
On Jan 7, 2015, at 11:22 AM, Gilles Gouaillardet 
 wrote:

> Valid options are :
> --with-threads e.g. --with-threads=posix e.g. default
> And
> --with-threads=no
> 
> Except configure will explicitly fail if --with-threads=no is used

Which is the moral equivalent of not having this option.  :-)  (which I think 
is your point :-) )

> So bottom line, pthreads and pthreads only are usable

But my question remains: we all decided that OMPI will *require* pthreads, 
right?  (i.e., configure will fail if pthreads are not available)

I am being pedantic here, I know -- but it's slightly different than what 
you're saying, and this threading stuff is already quite confusing...


> Cheers,
> 
> Gilles 
> 
> "Jeff Squyres (jsquyres)" さんのメール:
>> On Jan 7, 2015, at 4:25 AM, Gilles Gouaillardet 
>>  wrote:
>> 
>>> 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 */
>> 
>> Did we decide this?  (that OMPI *requires* pthreads)
>> 
>> I *think* we did.  But I just want to make sure that my (terrible) memory is 
>> correct...
>> 
>>> 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
>> 
>> Sounds good.
>> 
>>> 2) step 1) + remove #ifdef OPAL_HAVE_POSIX_THREADS and remove dead code
>>> (e.g. #ifndef OPAL_HAVE_POSIX_THREADS)
>> 
>> Also make configure fail if pthreads are not available.
>> 
>>> 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.
>> 
>> I think the consensus was that pthreads are fine for the foreseeable future. 
>>  If we need to re-add the threading abstraction layer, it's annoying, but 
>> not difficult.  Might as well simplify what we have, since there's no other 
>> threading system on the horizon that we need to worry about.
>> 
>> -- 
>> 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/16750.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/16751.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] pthreads (was: Re: RFC: remove --disable-smp-locks)

2015-01-07 Thread Gilles Gouaillardet 
Valid options are :
--with-threads e.g. --with-threads=posix e.g. default
And
--with-threads=no

Except configure will explicitly fail if --with-threads=no is used

So bottom line, pthreads and pthreads only are usable

Cheers,

Gilles 

"Jeff Squyres (jsquyres)" さんのメール:
>On Jan 7, 2015, at 4:25 AM, Gilles Gouaillardet 
> wrote:
>
>> 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 */
>
>Did we decide this?  (that OMPI *requires* pthreads)
>
>I *think* we did.  But I just want to make sure that my (terrible) memory is 
>correct...
>
>> 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
>
>Sounds good.
>
>> 2) step 1) + remove #ifdef OPAL_HAVE_POSIX_THREADS and remove dead code
>> (e.g. #ifndef OPAL_HAVE_POSIX_THREADS)
>
>Also make configure fail if pthreads are not available.
>
>> 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.
>
>I think the consensus was that pthreads are fine for the foreseeable future.  
>If we need to re-add the threading abstraction layer, it's annoying, but not 
>difficult.  Might as well simplify what we have, since there's no other 
>threading system on the horizon that we need to worry about.
>
>-- 
>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/16750.php

[OMPI devel] pthreads (was: Re: RFC: remove --disable-smp-locks)

2015-01-07 Thread Jeff Squyres (jsquyres) 
On Jan 7, 2015, at 4:25 AM, Gilles Gouaillardet  
wrote:

> 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 */

Did we decide this?  (that OMPI *requires* pthreads)

I *think* we did.  But I just want to make sure that my (terrible) memory is 
correct...

> 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

Sounds good.

> 2) step 1) + remove #ifdef OPAL_HAVE_POSIX_THREADS and remove dead code
> (e.g. #ifndef OPAL_HAVE_POSIX_THREADS)

Also make configure fail if pthreads are not available.

> 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.

I think the consensus was that pthreads are fine for the foreseeable future.  
If we need to re-add the threading abstraction layer, it's annoying, but not 
difficult.  Might as well simplify what we have, since there's no other 
threading system on the horizon that we need to worry about.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/