* Using pthread_t as a key in a map @ 2006-05-09 20:55 Paolo Brandoli 2006-05-15 2:23 ` Will Bryant 0 siblings, 1 reply; 7+ messages in thread From: Paolo Brandoli @ 2006-05-09 20:55 UTC (permalink / raw) To: pthreads-win32 I have a source code that uses the pthread_t as a key in a std::map. Because pthread-win32 defines pthread_t as a structure, the compilation fails. I added the following lines in my pthread.h header in order to allow the usage of pthread_t in the map: bool operator < (const ptw32_handle_t& left, const ptw32_handle_t& right) { return left.p < right.p; } bool operator > (const ptw32_handle_t& left, const ptw32_handle_t& right) { return left.p > right.p; } Bye Paolo Brandoli http://www.puntoexe.com ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Using pthread_t as a key in a map 2006-05-09 20:55 Using pthread_t as a key in a map Paolo Brandoli @ 2006-05-15 2:23 ` Will Bryant 2006-05-15 11:57 ` Paolo Brandoli 2006-05-15 14:24 ` Ross Johnson 0 siblings, 2 replies; 7+ messages in thread From: Will Bryant @ 2006-05-15 2:23 UTC (permalink / raw) To: pthreads-win32 Hi Paolo, Bear in mind that pthreads-win32 is written in C, and operator overloading is a C++ feature, so adding that would prevent pthreads-win32 from compiling with C apps. One alternative is to make a custom comparator type and use that in the map declaration - or you could even simply move those operator overloads to your own units (they don't have to be defined where the type being compared is declared, as long as they've visible at the point where they're used - ie. your map declaration). But bear in mind that in any case, making use of the ptw32_handle_t type makes your code nonportable, and since portability is generally the reason one is using pthreads-win32 in the first place, this is perhaps not the best design for general use. Will Paolo Brandoli wrote: > I have a source code that uses the pthread_t as a key in a std::map. > Because pthread-win32 defines pthread_t as a structure, the > compilation fails. > > I added the following lines in my pthread.h header in order to allow > the usage of pthread_t in the map: > > bool operator < (const ptw32_handle_t& left, const ptw32_handle_t& right) > { > return left.p < right.p; > } > > bool operator > (const ptw32_handle_t& left, const ptw32_handle_t& right) > { > return left.p > right.p; > } > > Bye > Paolo Brandoli > http://www.puntoexe.com > -- Will Bryant ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Using pthread_t as a key in a map 2006-05-15 2:23 ` Will Bryant @ 2006-05-15 11:57 ` Paolo Brandoli 2006-05-15 14:02 ` Robert Kindred 2006-05-15 14:24 ` Ross Johnson 1 sibling, 1 reply; 7+ messages in thread From: Paolo Brandoli @ 2006-05-15 11:57 UTC (permalink / raw) To: pthreads-win32 Hi Will, What I'm trying to do is to order the pthread_t pointers so I can simulate the windows function "WaitForMultipleObjects"; I have to order the pthread_t in a consistent way before attempting to lock several mutexes at once. The way the pthread_t is defined in the library doesn't allow to use the < and > operators; those operators can be used when pthread_t is defined as a pointer (like in the pthreads implementation on posix systems) and not as a structure containing a pointer (as in win32-pthread). I defined the operator for ptw32_handle_t, but it works for pthread_t (since it is a synonim for ptw32_handle_t). Anyway your considerations are right since this breaks the compilation on C compilers. On C++ compilers it just remove the errors when I try to compare two pthread_t values. I'm trying to find a more elegant solution, but I'm just staring at the monitor and nothing pops up in my brain. Paolo Brandoli On 5/15/06, Will Bryant <will.bryant@ecosm.com> wrote: > Hi Paolo, > > Bear in mind that pthreads-win32 is written in C, and operator > overloading is a C++ feature, so adding that would prevent > pthreads-win32 from compiling with C apps. > > One alternative is to make a custom comparator type and use that in the > map declaration - or you could even simply move those operator overloads > to your own units (they don't have to be defined where the type being > compared is declared, as long as they've visible at the point where > they're used - ie. your map declaration). > > But bear in mind that in any case, making use of the ptw32_handle_t type > makes your code nonportable, and since portability is generally the > reason one is using pthreads-win32 in the first place, this is perhaps > not the best design for general use. > > Will > > > Paolo Brandoli wrote: > > I have a source code that uses the pthread_t as a key in a std::map. > > Because pthread-win32 defines pthread_t as a structure, the > > compilation fails. > > > > I added the following lines in my pthread.h header in order to allow > > the usage of pthread_t in the map: > > > > bool operator < (const ptw32_handle_t& left, const ptw32_handle_t& right) > > { > > return left.p < right.p; > > } > > > > bool operator > (const ptw32_handle_t& left, const ptw32_handle_t& right) > > { > > return left.p > right.p; > > } > > > > Bye > > Paolo Brandoli > > http://www.puntoexe.com > > > > > -- > Will Bryant > > > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: Using pthread_t as a key in a map 2006-05-15 11:57 ` Paolo Brandoli @ 2006-05-15 14:02 ` Robert Kindred 0 siblings, 0 replies; 7+ messages in thread From: Robert Kindred @ 2006-05-15 14:02 UTC (permalink / raw) To: Paolo Brandoli, pthreads-win32 I have gotten a lot of my tricks from a book which has the acronym of POSA2. This stands for "Pattern-Oriented Software Architecture" Volume 2, by Douglas Schmidt. It is a book about concurrent and network programming. This is the book that explains a lot of the design of ACE (Adaptive Communiations Environment). However, I do not use ACE. Robert Kindred > -----Original Message----- > From: pthreads-win32-owner@sourceware.org > [mailto:pthreads-win32-owner@sourceware.org]On Behalf Of Paolo Brandoli > Sent: Monday, May 15, 2006 6:57 AM > To: pthreads-win32@sourceware.org > Subject: Re: Using pthread_t as a key in a map > > > Hi Will, > > What I'm trying to do is to order the pthread_t pointers so I can > simulate the windows function "WaitForMultipleObjects"; I have to > order the pthread_t in a consistent way before attempting to lock > several mutexes at once. > > The way the pthread_t is defined in the library doesn't allow to use > the < and > operators; those operators can be used when pthread_t is > defined as a pointer (like in the pthreads implementation on posix > systems) and not as a structure containing a pointer (as in > win32-pthread). > > I defined the operator for ptw32_handle_t, but it works for pthread_t > (since it is a synonim for ptw32_handle_t). > > Anyway your considerations are right since this breaks the compilation > on C compilers. On C++ compilers it just remove the errors when I try > to compare two pthread_t values. > > I'm trying to find a more elegant solution, but I'm just staring at > the monitor and nothing pops up in my brain. > > Paolo Brandoli > > On 5/15/06, Will Bryant <will.bryant@ecosm.com> wrote: > > Hi Paolo, > > > > Bear in mind that pthreads-win32 is written in C, and operator > > overloading is a C++ feature, so adding that would prevent > > pthreads-win32 from compiling with C apps. > > > > One alternative is to make a custom comparator type and use that in the > > map declaration - or you could even simply move those operator overloads > > to your own units (they don't have to be defined where the type being > > compared is declared, as long as they've visible at the point where > > they're used - ie. your map declaration). > > > > But bear in mind that in any case, making use of the ptw32_handle_t type > > makes your code nonportable, and since portability is generally the > > reason one is using pthreads-win32 in the first place, this is perhaps > > not the best design for general use. > > > > Will > > > > > > Paolo Brandoli wrote: > > > I have a source code that uses the pthread_t as a key in a std::map. > > > Because pthread-win32 defines pthread_t as a structure, the > > > compilation fails. > > > > > > I added the following lines in my pthread.h header in order to allow > > > the usage of pthread_t in the map: > > > > > > bool operator < (const ptw32_handle_t& left, const > ptw32_handle_t& right) > > > { > > > return left.p < right.p; > > > } > > > > > > bool operator > (const ptw32_handle_t& left, const > ptw32_handle_t& right) > > > { > > > return left.p > right.p; > > > } > > > > > > Bye > > > Paolo Brandoli > > > http://www.puntoexe.com > > > > > > > > > -- > > Will Bryant > > > > > > > > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Using pthread_t as a key in a map 2006-05-15 2:23 ` Will Bryant 2006-05-15 11:57 ` Paolo Brandoli @ 2006-05-15 14:24 ` Ross Johnson 2006-05-16 1:17 ` Ross Johnson 1 sibling, 1 reply; 7+ messages in thread From: Ross Johnson @ 2006-05-15 14:24 UTC (permalink / raw) To: pthreads-win32 A reasonably portable solution to this came up the other day (privately) in relation to using pthreads-win32 pthread_t with openssl. It is the following: #define PT(t) (*((unsigned long *)&(t))) pthread_t thrA, thrB; ... PT(thrA) < PT(thrB) etc. Although this still relies on the pointer component being at offset 0 inside the pthread_t struct (which was made this way deliberately so probably won't change in the future), it does avoid having to explicitly use or know about ptw32_handle_t. You still lose the handle uniqueness "guarantee" that the pthread_t struct provides though, so that you then need to take extra care that the threads that you do this with don't detach without you realising it. By the way, the pthread_t in pthreads-win32 is POSIX compliant. POSIX doesn't require pthread_t to be a scalar type, and in fact all but requires that POSIX compliant applications not presume the type of pthread_t. Ross Will Bryant wrote: >Hi Paolo, > >Bear in mind that pthreads-win32 is written in C, and operator >overloading is a C++ feature, so adding that would prevent >pthreads-win32 from compiling with C apps. > >One alternative is to make a custom comparator type and use that in the >map declaration - or you could even simply move those operator overloads >to your own units (they don't have to be defined where the type being >compared is declared, as long as they've visible at the point where >they're used - ie. your map declaration). > >But bear in mind that in any case, making use of the ptw32_handle_t type >makes your code nonportable, and since portability is generally the >reason one is using pthreads-win32 in the first place, this is perhaps >not the best design for general use. > >Will > > >Paolo Brandoli wrote: > > >>I have a source code that uses the pthread_t as a key in a std::map. >>Because pthread-win32 defines pthread_t as a structure, the >>compilation fails. >> >>I added the following lines in my pthread.h header in order to allow >>the usage of pthread_t in the map: >> >>bool operator < (const ptw32_handle_t& left, const ptw32_handle_t& right) >>{ >> return left.p < right.p; >>} >> >>bool operator > (const ptw32_handle_t& left, const ptw32_handle_t& right) >>{ >> return left.p > right.p; >>} >> >>Bye >>Paolo Brandoli >>http://www.puntoexe.com >> >> >> > > > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Using pthread_t as a key in a map 2006-05-15 14:24 ` Ross Johnson @ 2006-05-16 1:17 ` Ross Johnson 2006-05-16 14:09 ` Paolo Brandoli 0 siblings, 1 reply; 7+ messages in thread From: Ross Johnson @ 2006-05-16 1:17 UTC (permalink / raw) To: pthreads-win32 Paolo, In your original message you said you were trying to create functionality similar to WaitForMultipleObjects(). In pthreads this is usually done using condition variables. I.e. similar to the way that WaitForMultipleObjects() returns the array index of the handle that caused it to return, or an error. The signaling thread will set the condition variable directly and the signaled (waiting) thread will check the condition variable directly. Re using pthread_t as a map key, the only compare operation that you can legally do on pthread_t is test for equality via pthread_equal(). Ross Ross Johnson wrote: > A reasonably portable solution to this came up the other day > (privately) in relation to using pthreads-win32 pthread_t with > openssl. It is the following: > > #define PT(t) (*((unsigned long *)&(t))) > pthread_t thrA, thrB; > ... > PT(thrA) < PT(thrB) > > etc. > > Although this still relies on the pointer component being at offset 0 > inside the pthread_t struct (which was made this way deliberately so > probably won't change in the future), it does avoid having to > explicitly use or know about ptw32_handle_t. You still lose the handle > uniqueness "guarantee" that the pthread_t struct provides though, so > that you then need to take extra care that the threads that you do > this with don't detach without you realising it. > > By the way, the pthread_t in pthreads-win32 is POSIX compliant. POSIX > doesn't require pthread_t to be a scalar type, and in fact all but > requires that POSIX compliant applications not presume the type of > pthread_t. > > Ross > > Will Bryant wrote: > >> Hi Paolo, >> >> Bear in mind that pthreads-win32 is written in C, and operator >> overloading is a C++ feature, so adding that would prevent >> pthreads-win32 from compiling with C apps. >> >> One alternative is to make a custom comparator type and use that in the >> map declaration - or you could even simply move those operator overloads >> to your own units (they don't have to be defined where the type being >> compared is declared, as long as they've visible at the point where >> they're used - ie. your map declaration). >> >> But bear in mind that in any case, making use of the ptw32_handle_t type >> makes your code nonportable, and since portability is generally the >> reason one is using pthreads-win32 in the first place, this is perhaps >> not the best design for general use. >> >> Will >> >> >> Paolo Brandoli wrote: >> >> >>> I have a source code that uses the pthread_t as a key in a std::map. >>> Because pthread-win32 defines pthread_t as a structure, the >>> compilation fails. >>> >>> I added the following lines in my pthread.h header in order to allow >>> the usage of pthread_t in the map: >>> >>> bool operator < (const ptw32_handle_t& left, const ptw32_handle_t& >>> right) >>> { >>> return left.p < right.p; >>> } >>> >>> bool operator > (const ptw32_handle_t& left, const ptw32_handle_t& >>> right) >>> { >>> return left.p > right.p; >>> } >>> >>> Bye >>> Paolo Brandoli >>> http://www.puntoexe.com >>> >>> >> >> >> >> >> > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Using pthread_t as a key in a map 2006-05-16 1:17 ` Ross Johnson @ 2006-05-16 14:09 ` Paolo Brandoli 0 siblings, 0 replies; 7+ messages in thread From: Paolo Brandoli @ 2006-05-16 14:09 UTC (permalink / raw) To: pthreads-win32 Thank you very much for your suggestions. I'm going to rewrite the WaitForMultipleObjects-like function. The function should wait until all the mutexes are available, but should NOT keep some of them locked (some cpu cycles are ok) until all of them become available. The code I wrote was based on an example from the IBM website (I think it was for the 360 series? I really don't remember...). I think that I will take this approach to order the mutexes I will include the pthread_t in a structure that contains a scalar unique ID. I will let you know how this task proceeds. Paolo On 5/16/06, Ross Johnson <rpj@callisto.canberra.edu.au> wrote: > Paolo, > > In your original message you said you were trying to create > functionality similar to WaitForMultipleObjects(). In pthreads this is > usually done using condition variables. I.e. similar to the way that > WaitForMultipleObjects() returns the array index of the handle that > caused it to return, or an error. The signaling thread will set the > condition variable directly and the signaled (waiting) thread will check > the condition variable directly. > > Re using pthread_t as a map key, the only compare operation that you can > legally do on pthread_t is test for equality via pthread_equal(). > > Ross > > Ross Johnson wrote: > > > A reasonably portable solution to this came up the other day > > (privately) in relation to using pthreads-win32 pthread_t with > > openssl. It is the following: > > > > #define PT(t) (*((unsigned long *)&(t))) > > pthread_t thrA, thrB; > > ... > > PT(thrA) < PT(thrB) > > > > etc. > > > > Although this still relies on the pointer component being at offset 0 > > inside the pthread_t struct (which was made this way deliberately so > > probably won't change in the future), it does avoid having to > > explicitly use or know about ptw32_handle_t. You still lose the handle > > uniqueness "guarantee" that the pthread_t struct provides though, so > > that you then need to take extra care that the threads that you do > > this with don't detach without you realising it. > > > > By the way, the pthread_t in pthreads-win32 is POSIX compliant. POSIX > > doesn't require pthread_t to be a scalar type, and in fact all but > > requires that POSIX compliant applications not presume the type of > > pthread_t. > > > > Ross > > > > Will Bryant wrote: > > > >> Hi Paolo, > >> > >> Bear in mind that pthreads-win32 is written in C, and operator > >> overloading is a C++ feature, so adding that would prevent > >> pthreads-win32 from compiling with C apps. > >> > >> One alternative is to make a custom comparator type and use that in the > >> map declaration - or you could even simply move those operator overloads > >> to your own units (they don't have to be defined where the type being > >> compared is declared, as long as they've visible at the point where > >> they're used - ie. your map declaration). > >> > >> But bear in mind that in any case, making use of the ptw32_handle_t type > >> makes your code nonportable, and since portability is generally the > >> reason one is using pthreads-win32 in the first place, this is perhaps > >> not the best design for general use. > >> > >> Will > >> > >> > >> Paolo Brandoli wrote: > >> > >> > >>> I have a source code that uses the pthread_t as a key in a std::map. > >>> Because pthread-win32 defines pthread_t as a structure, the > >>> compilation fails. > >>> > >>> I added the following lines in my pthread.h header in order to allow > >>> the usage of pthread_t in the map: > >>> > >>> bool operator < (const ptw32_handle_t& left, const ptw32_handle_t& > >>> right) > >>> { > >>> return left.p < right.p; > >>> } > >>> > >>> bool operator > (const ptw32_handle_t& left, const ptw32_handle_t& > >>> right) > >>> { > >>> return left.p > right.p; > >>> } > >>> > >>> Bye > >>> Paolo Brandoli > >>> http://www.puntoexe.com > >>> > >>> > >> > >> > >> > >> > >> > > > > ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-05-16 14:09 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-05-09 20:55 Using pthread_t as a key in a map Paolo Brandoli 2006-05-15 2:23 ` Will Bryant 2006-05-15 11:57 ` Paolo Brandoli 2006-05-15 14:02 ` Robert Kindred 2006-05-15 14:24 ` Ross Johnson 2006-05-16 1:17 ` Ross Johnson 2006-05-16 14:09 ` Paolo Brandoli
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).