public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: Ross Johnson <Ross.Johnson@homemail.com.au>
To: Tobias Ljunggren <jtl@myrealbox.com>
Cc: pthreads-win32@sourceware.org
Subject: Re: pthread_t and stl maps
Date: Tue, 31 Mar 2009 13:33:00 -0000	[thread overview]
Message-ID: <49D21BA0.6010202@homemail.com.au> (raw)
In-Reply-To: <1238493105.d943181cjtl@myrealbox.com>

Tobias Ljunggren wrote:
> Hello,
>
> I've been using pthreads-win32 (rel 2.7.0) for some time but recently changed to current head in CVS due to win64 support.
>
> First of all I must say that the upgrade from 2.7.0 was easier than I thought. A good work to all of you who are involved with the development!
>
> I use the same code base for both Linux and Windows builds and it works great.
>
> I use a stl map to store some static data that are shared within the same thread but not by other threads. The change of pthread_t to a struct requires a sort function if the key in a map is a thread identifier (pthread_t).
>
> What should the correct ordering be? I looked at the code in pthread_equal and guess that "(left.p < right.p)" isn't enough but is (left.p < right.p && left.x < right.x) ok?
>   
Hi Tobias,

pthread_t, as with most of the pthread*_t types, is intended to be 
opaque to applications, so you should not be making any assumptions 
about it's representation and should not be doing much other than 
storing it or retrieving it or testing it for equality, e.g. using 
pthread_equal().

Having said that, you could use a union like this, which makes no 
assumptions about pthread_t and so should be portable:-

typedef union {
    pthread_t   pth;
    unsigned char b[sizeof(pthread_t)];
} pthcmp_t;

int pthcmp(pthread_t left, pthread_t right)
{
    /*
     * Compare two pthread handles in a way that imposes a repeatable 
but arbitrary
     * ordering on them.
     * I.e. given the same set of pthread_t handles the ordering should 
be the same
     * each time but the order has no particular meaning other than 
that. E.g.
     * the ordering does not imply the thread start sequence, or any other
     * relationship between threads.
     *
     * Return values are:
     *    1 : left is greater than right
     *    0 : left is equal to right
     *    -1 : left is less than right
     */
    int i;
    pthcmp_t L, R;
    L.pth = left;
    R.pth = right;
    for (i = 0; i < sizeof(pthread_t); i++)
    {
        if (L.b[i] > R.b[i])
            return 1;
        else if (L.b[i] < R.b[i])
            return -1;
    }
    return 0;
}

> Best regards,
> Tobias
>
>   

      reply	other threads:[~2009-03-31 13:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-31 10:27 Tobias Ljunggren
2009-03-31 13:33 ` Ross Johnson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49D21BA0.6010202@homemail.com.au \
    --to=ross.johnson@homemail.com.au \
    --cc=jtl@myrealbox.com \
    --cc=pthreads-win32@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).