Re: [OMPI devel] Rest of OMPI meeting notes up
I updated the notes -- better now? On Jun 6, 2013, at 10:09 AM, Ralph Castain wrote: > Hmmmthere seem to be some typos in this posting. For example, you say > that both I and Aure will do the orte classes for the single-vs-multi thread > APIs. Could you take a glance thru it and clean up a bit? I'm not sure which > answer is correct. > > > On Jun 6, 2013, at 7:56 AM, Jeff Squyres (jsquyres) > wrote: > >> I finally posted the rest of the meeting notes. Pay particular attention to >> what was discussed and the action items from Tuesday: >> >> https://svn.open-mpi.org/trac/ompi/wiki/Jun13Meeting >> >> -- >> 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 >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] Rest of OMPI meeting notes up
Yes - thanks! One note about the threading changes. We will need to sequence those a bit. IIRC, the current OOB isn't happy when you turn on opal thread support and can "wedge" itself. I also suspect we'll want the MPI_Waitall fix before we enable thread multiple by default. On Jun 7, 2013, at 5:11 AM, Jeff Squyres (jsquyres) wrote: > I updated the notes -- better now? > > On Jun 6, 2013, at 10:09 AM, Ralph Castain wrote: > >> Hmmmthere seem to be some typos in this posting. For example, you say >> that both I and Aure will do the orte classes for the single-vs-multi thread >> APIs. Could you take a glance thru it and clean up a bit? I'm not sure which >> answer is correct. >> >> >> On Jun 6, 2013, at 7:56 AM, Jeff Squyres (jsquyres) >> wrote: >> >>> I finally posted the rest of the meeting notes. Pay particular attention >>> to what was discussed and the action items from Tuesday: >>> >>> https://svn.open-mpi.org/trac/ompi/wiki/Jun13Meeting >>> >>> -- >>> 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 >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> >> ___ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > -- > 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 > http://www.open-mpi.org/mailman/listinfo.cgi/devel
[OMPI devel] RFC: Add static initializer for opal_mutex_t
What: Add a static initializer for opal_mutex_t for both posix and solaris
threads.
Why: Enables the use of opal locks that don't have to be OBJ_CONSTRUCT'ed.
When: This is a trivial addition but I would like some review/testing of the
code (I don't have solaris). Setting timeout to Tuesday, June 11, 2013
diff --git a/opal/threads/mutex_unix.h b/opal/threads/mutex_unix.h
index 27528e6..28b1744 100644
--- a/opal/threads/mutex_unix.h
+++ b/opal/threads/mutex_unix.h
@@ -81,6 +81,25 @@ OPAL_DECLSPEC OBJ_CLASS_DECLARATION(opal_mutex_t);
* POSIX threads
/
+#if !OPAL_ENABLE_MULTI_THREADS && OPAL_ENABLE_DEBUG
+#define OPAL_MUTEX_STATIC_INIT \
+ { \
+ .super = OPAL_OBJ_STATIC_INIT(opal_object_t), \
+ .m_lock_pthread = PTHREAD_MUTEX_INITIALIZER, \
+ .m_lock_debug = 0,\
+ .m_lock_file = NULL, \
+ .m_lock_line = 0, \
+ .m_lock_atomic = 0\
+ }
+#else
+#define OPAL_MUTEX_STATIC_INIT \
+ { \
+ .super = OPAL_OBJ_STATIC_INIT(opal_object_t), \
+ .m_lock_pthread = PTHREAD_MUTEX_INITIALIZER, \
+ .m_lock_atomic = 0\
+ }
+#endif
+
static inline int opal_mutex_trylock(opal_mutex_t *m)
{
#if OPAL_ENABLE_DEBUG
@@ -130,6 +149,25 @@ static inline void opal_mutex_unlock(opal_mutex_t *m)
* Solaris threads
/
+#if !OPAL_ENABLE_MULTI_THREADS && OPAL_ENABLE_DEBUG
+#define OPAL_MUTEX_STATIC_INIT \
+ { \
+ .super = OPAL_OBJ_STATIC_INIT(opal_object_t), \
+ .m_lock_solaris = DEFAULTMUTEX, \
+ .m_lock_debug = 0,\
+ .m_lock_file = NULL, \
+ .m_lock_line = 0, \
+ .m_lock_atomic = 0\
+ }
+#else
+#define OPAL_MUTEX_STATIC_INIT \
+ { \
+ .super = OPAL_OBJ_STATIC_INIT(opal_object_t), \
+ .m_lock_solaris = DEFAULTMUTEX, \
+ .m_lock_atomic = 0\
+ }
+#endif
+
static inline int opal_mutex_trylock(opal_mutex_t *m)
{
Re: [OMPI devel] RFC: Add static initializer for opal_mutex_t
Nathan forgot to mention that we didn't have this before because of Windows.
But now we don't have Windows support, so...
On Jun 7, 2013, at 9:01 AM, "Hjelm, Nathan T" wrote:
> What: Add a static initializer for opal_mutex_t for both posix and solaris
> threads.
>
> Why: Enables the use of opal locks that don't have to be OBJ_CONSTRUCT'ed.
>
> When: This is a trivial addition but I would like some review/testing of the
> code (I don't have solaris). Setting timeout to Tuesday, June 11, 2013
>
>
> diff --git a/opal/threads/mutex_unix.h b/opal/threads/mutex_unix.h
> index 27528e6..28b1744 100644
> --- a/opal/threads/mutex_unix.h
> +++ b/opal/threads/mutex_unix.h
> @@ -81,6 +81,25 @@ OPAL_DECLSPEC OBJ_CLASS_DECLARATION(opal_mutex_t);
> * POSIX threads
> /
>
> +#if !OPAL_ENABLE_MULTI_THREADS && OPAL_ENABLE_DEBUG
> +#define OPAL_MUTEX_STATIC_INIT \
> + { \
> + .super = OPAL_OBJ_STATIC_INIT(opal_object_t), \
> + .m_lock_pthread = PTHREAD_MUTEX_INITIALIZER, \
> + .m_lock_debug = 0,\
> + .m_lock_file = NULL, \
> + .m_lock_line = 0, \
> + .m_lock_atomic = 0\
> + }
> +#else
> +#define OPAL_MUTEX_STATIC_INIT \
> + { \
> + .super = OPAL_OBJ_STATIC_INIT(opal_object_t), \
> + .m_lock_pthread = PTHREAD_MUTEX_INITIALIZER, \
> + .m_lock_atomic = 0\
> + }
> +#endif
> +
> static inline int opal_mutex_trylock(opal_mutex_t *m)
> {
> #if OPAL_ENABLE_DEBUG
> @@ -130,6 +149,25 @@ static inline void opal_mutex_unlock(opal_mutex_t *m)
> * Solaris threads
> /
>
> +#if !OPAL_ENABLE_MULTI_THREADS && OPAL_ENABLE_DEBUG
> +#define OPAL_MUTEX_STATIC_INIT \
> + { \
> + .super = OPAL_OBJ_STATIC_INIT(opal_object_t), \
> + .m_lock_solaris = DEFAULTMUTEX, \
> + .m_lock_debug = 0,\
> + .m_lock_file = NULL, \
> + .m_lock_line = 0, \
> + .m_lock_atomic = 0\
> + }
> +#else
> +#define OPAL_MUTEX_STATIC_INIT \
> + { \
> + .super = OPAL_OBJ_STATIC_INIT(opal_object_t), \
> + .m_lock_solaris = DEFAULTMUTEX, \
> + .m_lock_atomic = 0\
> + }
> +#endif
> +
>
> static inline int opal_mutex_trylock(opal_mutex_t *m)
> {
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] RFC: Add static initializer for opal_mutex_t
Im curious to know why Windows support is to be blamed for the lack of such
functionality?
George.
On Jun 7, 2013, at 18:08 , Jeff Squyres (jsquyres) wrote:
> Nathan forgot to mention that we didn't have this before because of Windows.
> But now we don't have Windows support, so...
>
>
> On Jun 7, 2013, at 9:01 AM, "Hjelm, Nathan T" wrote:
>
>> What: Add a static initializer for opal_mutex_t for both posix and solaris
>> threads.
>>
>> Why: Enables the use of opal locks that don't have to be OBJ_CONSTRUCT'ed.
>>
>> When: This is a trivial addition but I would like some review/testing of the
>> code (I don't have solaris). Setting timeout to Tuesday, June 11, 2013
>>
>>
>> diff --git a/opal/threads/mutex_unix.h b/opal/threads/mutex_unix.h
>> index 27528e6..28b1744 100644
>> --- a/opal/threads/mutex_unix.h
>> +++ b/opal/threads/mutex_unix.h
>> @@ -81,6 +81,25 @@ OPAL_DECLSPEC OBJ_CLASS_DECLARATION(opal_mutex_t);
>> * POSIX threads
>> /
>>
>> +#if !OPAL_ENABLE_MULTI_THREADS && OPAL_ENABLE_DEBUG
>> +#define OPAL_MUTEX_STATIC_INIT \
>> + { \
>> + .super = OPAL_OBJ_STATIC_INIT(opal_object_t), \
>> + .m_lock_pthread = PTHREAD_MUTEX_INITIALIZER, \
>> + .m_lock_debug = 0,\
>> + .m_lock_file = NULL, \
>> + .m_lock_line = 0, \
>> + .m_lock_atomic = 0\
>> + }
>> +#else
>> +#define OPAL_MUTEX_STATIC_INIT \
>> + { \
>> + .super = OPAL_OBJ_STATIC_INIT(opal_object_t), \
>> + .m_lock_pthread = PTHREAD_MUTEX_INITIALIZER, \
>> + .m_lock_atomic = 0\
>> + }
>> +#endif
>> +
>> static inline int opal_mutex_trylock(opal_mutex_t *m)
>> {
>> #if OPAL_ENABLE_DEBUG
>> @@ -130,6 +149,25 @@ static inline void opal_mutex_unlock(opal_mutex_t *m)
>> * Solaris threads
>> /
>>
>> +#if !OPAL_ENABLE_MULTI_THREADS && OPAL_ENABLE_DEBUG
>> +#define OPAL_MUTEX_STATIC_INIT \
>> + { \
>> + .super = OPAL_OBJ_STATIC_INIT(opal_object_t), \
>> + .m_lock_solaris = DEFAULTMUTEX, \
>> + .m_lock_debug = 0,\
>> + .m_lock_file = NULL, \
>> + .m_lock_line = 0, \
>> + .m_lock_atomic = 0\
>> + }
>> +#else
>> +#define OPAL_MUTEX_STATIC_INIT \
>> + { \
>> + .super = OPAL_OBJ_STATIC_INIT(opal_object_t), \
>> + .m_lock_solaris = DEFAULTMUTEX, \
>> + .m_lock_atomic = 0\
>> + }
>> +#endif
>> +
>>
>> static inline int opal_mutex_trylock(opal_mutex_t *m)
>> {
>>
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
> --
> 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
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] RFC: Add static initializer for opal_mutex_t
Perhaps I was wrong -- I thought we had no static initializer because there was
no static initializer for mutexes in windows.
On Jun 7, 2013, at 9:28 AM, George Bosilca wrote:
> Im curious to know why Windows support is to be blamed for the lack of such
> functionality?
>
> George.
>
> On Jun 7, 2013, at 18:08 , Jeff Squyres (jsquyres) wrote:
>
>> Nathan forgot to mention that we didn't have this before because of Windows.
>> But now we don't have Windows support, so...
>>
>>
>> On Jun 7, 2013, at 9:01 AM, "Hjelm, Nathan T" wrote:
>>
>>> What: Add a static initializer for opal_mutex_t for both posix and solaris
>>> threads.
>>>
>>> Why: Enables the use of opal locks that don't have to be OBJ_CONSTRUCT'ed.
>>>
>>> When: This is a trivial addition but I would like some review/testing of
>>> the code (I don't have solaris). Setting timeout to Tuesday, June 11, 2013
>>>
>>>
>>> diff --git a/opal/threads/mutex_unix.h b/opal/threads/mutex_unix.h
>>> index 27528e6..28b1744 100644
>>> --- a/opal/threads/mutex_unix.h
>>> +++ b/opal/threads/mutex_unix.h
>>> @@ -81,6 +81,25 @@ OPAL_DECLSPEC OBJ_CLASS_DECLARATION(opal_mutex_t);
>>> * POSIX threads
>>> /
>>>
>>> +#if !OPAL_ENABLE_MULTI_THREADS && OPAL_ENABLE_DEBUG
>>> +#define OPAL_MUTEX_STATIC_INIT \
>>> + { \
>>> + .super = OPAL_OBJ_STATIC_INIT(opal_object_t), \
>>> + .m_lock_pthread = PTHREAD_MUTEX_INITIALIZER, \
>>> + .m_lock_debug = 0,\
>>> + .m_lock_file = NULL, \
>>> + .m_lock_line = 0, \
>>> + .m_lock_atomic = 0\
>>> + }
>>> +#else
>>> +#define OPAL_MUTEX_STATIC_INIT \
>>> + { \
>>> + .super = OPAL_OBJ_STATIC_INIT(opal_object_t), \
>>> + .m_lock_pthread = PTHREAD_MUTEX_INITIALIZER, \
>>> + .m_lock_atomic = 0\
>>> + }
>>> +#endif
>>> +
>>> static inline int opal_mutex_trylock(opal_mutex_t *m)
>>> {
>>> #if OPAL_ENABLE_DEBUG
>>> @@ -130,6 +149,25 @@ static inline void opal_mutex_unlock(opal_mutex_t *m)
>>> * Solaris threads
>>> /
>>>
>>> +#if !OPAL_ENABLE_MULTI_THREADS && OPAL_ENABLE_DEBUG
>>> +#define OPAL_MUTEX_STATIC_INIT \
>>> + { \
>>> + .super = OPAL_OBJ_STATIC_INIT(opal_object_t), \
>>> + .m_lock_solaris = DEFAULTMUTEX, \
>>> + .m_lock_debug = 0,\
>>> + .m_lock_file = NULL, \
>>> + .m_lock_line = 0, \
>>> + .m_lock_atomic = 0\
>>> + }
>>> +#else
>>> +#define OPAL_MUTEX_STATIC_INIT \
>>> + { \
>>> + .super = OPAL_OBJ_STATIC_INIT(opal_object_t), \
>>> + .m_lock_solaris = DEFAULTMUTEX, \
>>> + .m_lock_atomic = 0\
>>> + }
>>> +#endif
>>> +
>>>
>>> static inline int opal_mutex_trylock(opal_mutex_t *m)
>>> {
>>>
>>> ___
>>> devel mailing list
>>> de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>>
>> --
>> 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
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
[OMPI devel] 'install-sh' in SVN
Hi, It looks like an auto-generated 'install-sh' was accidentally added to SVN under libevent in OPAL: ompi-trunk/opal/mca/event/libevent2021/libevent/install-sh Ok, to remove it? --tjn _ Thomas Naughton naught...@ornl.gov Research Associate (865) 576-4184
Re: [OMPI devel] 'install-sh' in SVN
Shirley. :-) On Jun 7, 2013, at 1:07 PM, Thomas Naughton wrote: > Hi, > > It looks like an auto-generated 'install-sh' was accidentally added to SVN > under libevent in OPAL: > >ompi-trunk/opal/mca/event/libevent2021/libevent/install-sh > > Ok, to remove it? > --tjn > > _ > Thomas Naughton naught...@ornl.gov > Research Associate (865) 576-4184 > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
