Sequenced-Before for g++ 4.1.2?

Sequenced-Before for g++ 4.1.2?

[Hei Chan]

Hi,

I am still on 4.1.2 (which defaults to use C98), and I wonder whether g++ 4.1.2 guarantees that everything happens before (e.g. write to a variable) will be reflected in another thread if:
1. there is no lock (e.g. pthread_mutex/spinlock) involving
2. the "another thread" is created (e.g. calling pthread_create) after the "write"

An concrete example:
class B {};

class A {
public:
   std::map<long, B*> m_myMap;
   A::A() {
       m_myMap[0] = new B();
       pthread_t threadID;
       pthread_create(&threadID, NULL, start, NULL);
   }
   static void* start(void*) {
       // use m_myMap[0] here, will this new thread sees everything happens before it gets created (e.g. m_myMap[0] contains the valid value)?
   }
}

Thanks in advance.


Cheers,
Hei

Re: Sequenced-Before for g++ 4.1.2?

[Ian Lance Taylor]

Hei Chan <structurechart@yahoo.com> writes:

> I am still on 4.1.2 (which defaults to use C98), and I wonder whether g++ 4.1.2 guarantees that everything happens before (e.g. write to a variable) will be reflected in another thread if:
> 1. there is no lock (e.g. pthread_mutex/spinlock) involving
> 2. the "another thread" is created (e.g. calling pthread_create) after the "write"

The relevant question for the compiler is whether it will issue all
writes to globally visible memory before calling pthread_create.  The
answer is: yes, it will.

The rest is up to your library.  I would expect that any pthread library
would have a memory barrier during pthread_create, in which case you
should be fine.

Ian

Re: Sequenced-Before for g++ 4.1.2?

[Hei Chan]

Hi Ian,

If the compiler will issue all writes to globablly visible memory before pthread_create() is called, isn't it true that it doesn't matter whether pthread library would have a memory barrier during pthread_create?

I am running into an odd issue that I added a key-value pair to std::map<long, Foo*> (a member variable) in a constructor, and then called pthread_create() in the constructoras well, but when the new thread tried to look up one of the key-value pairs, I got a segfault inside std::map<long, Foo*>::find().  I could only think of when I tried to read the map, and the OS was trying to make the previous writes to the map visible to the new thread.  And such crash only happened 1% of the time.


Nowhere in my code changes the map except inside the constructor, and I printed out the key before I inserted it into the map.  When I ran gdb, I saw the key value and I did see the key in the log as well.


Cheers,
Hei



----- Original Message -----
From: Ian Lance Taylor <iant@google.com>
To: Hei Chan <structurechart@yahoo.com>
Cc: "gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>
Sent: Friday, April 13, 2012 10:46 PM
Subject: Re: Sequenced-Before for g++ 4.1.2?

Hei Chan <structurechart@yahoo.com> writes:

> I am still on 4.1.2 (which defaults to use C98), and I wonder whether g++ 4.1.2 guarantees that everything happens before (e.g. write to a variable) will be reflected in another thread if:
> 1. there is no lock (e.g. pthread_mutex/spinlock) involving
> 2. the "another thread" is created (e.g. calling pthread_create) after the "write"

The relevant question for the compiler is whether it will issue all
writes to globally visible memory before calling pthread_create.  The
answer is: yes, it will.

The rest is up to your library.  I would expect that any pthread library
would have a memory barrier during pthread_create, in which case you
should be fine.

Ian

Re: Sequenced-Before for g++ 4.1.2?

[Ian Lance Taylor]

Hei Chan <structurechart@yahoo.com> writes:

> If the compiler will issue all writes to globablly visible memory
> before pthread_create() is called, isn't it true that it doesn't
> matter whether pthread library would have a memory barrier during
> pthread_create?

No.  You have to consider caching effects.  With no memory barriers at
all the new thread, running on a different processor, may not see the
changes written to memory by the first processor.


> I am running into an odd issue that I added a key-value pair to
> std::map<long, Foo*> (a member variable) in a constructor, and then
> called pthread_create() in the constructoras well, but when the new
> thread tried to look up one of the key-value pairs, I got a segfault
> inside std::map<long, Foo*>::find().  I could only think of when I
> tried to read the map, and the OS was trying to make the previous
> writes to the map visible to the new thread.  And such crash only
> happened 1% of the time.
>
>
> Nowhere in my code changes the map except inside the constructor, and
> I printed out the key before I inserted it into the map.  When I ran
> gdb, I saw the key value and I did see the key in the log as well.

Do you do anything to ensure that the new thread does not access the map
until the constructor has completed?  I think that such a lock would be
required.  Other than that, I think we would have to see a test case.

Ian


> ----- Original Message -----
> From: Ian Lance Taylor <iant@google.com>
> To: Hei Chan <structurechart@yahoo.com>
> Cc: "gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>
> Sent: Friday, April 13, 2012 10:46 PM
> Subject: Re: Sequenced-Before for g++ 4.1.2?
>
> Hei Chan <structurechart@yahoo.com> writes:
>
>> I am still on 4.1.2 (which defaults to use C98), and I wonder whether g++ 4.1.2 guarantees that everything happens before (e.g. write to a variable) will be reflected in another thread if:
>> 1. there is no lock (e.g. pthread_mutex/spinlock) involving
>> 2. the "another thread" is created (e.g. calling pthread_create) after the "write"
>
> The relevant question for the compiler is whether it will issue all
> writes to globally visible memory before calling pthread_create.  The
> answer is: yes, it will.
>
> The rest is up to your library.  I would expect that any pthread library
> would have a memory barrier during pthread_create, in which case you
> should be fine.
>
> Ian

Re: Sequenced-Before for g++ 4.1.2?

[Hei Chan]

Hi Ian,

I probably misinterpreted what you meant about "globally visible memory".  I thought you meant that all threads would see the same copy.  What does "globally visible memory" refer to?

I didn't do anything to prevent anyone from accessing the map because I thought what was changed before pthread_create() would be visible by the newly created thread.  Maybe it has nothing to do with the cache but an incomplete object..


Cheers,
Hei



----- Original Message -----
From: Ian Lance Taylor <iant@google.com>
To: Hei Chan <structurechart@yahoo.com>
Cc: "gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>
Sent: Monday, April 16, 2012 9:33 AM
Subject: Re: Sequenced-Before for g++ 4.1.2?

Hei Chan <structurechart@yahoo.com> writes:

> If the compiler will issue all writes to globablly visible memory
> before pthread_create() is called, isn't it true that it doesn't
> matter whether pthread library would have a memory barrier during
> pthread_create?

No.  You have to consider caching effects.  With no memory barriers at
all the new thread, running on a different processor, may not see the
changes written to memory by the first processor.


> I am running into an odd issue that I added a key-value pair to
> std::map<long, Foo*> (a member variable) in a constructor, and then
> called pthread_create() in the constructoras well, but when the new
> thread tried to look up one of the key-value pairs, I got a segfault
> inside std::map<long, Foo*>::find().  I could only think of when I
> tried to read the map, and the OS was trying to make the previous
> writes to the map visible to the new thread.  And such crash only
> happened 1% of the time.
>
>
> Nowhere in my code changes the map except inside the constructor, and
> I printed out the key before I inserted it into the map.  When I ran
> gdb, I saw the key value and I did see the key in the log as well.

Do you do anything to ensure that the new thread does not access the map
until the constructor has completed?  I think that such a lock would be
required.  Other than that, I think we would have to see a test case.

Ian


> ----- Original Message -----
> From: Ian Lance Taylor <iant@google.com>
> To: Hei Chan <structurechart@yahoo.com>
> Cc: "gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>
> Sent: Friday, April 13, 2012 10:46 PM
> Subject: Re: Sequenced-Before for g++ 4.1.2?
>
> Hei Chan <structurechart@yahoo.com> writes:
>
>> I am still on 4.1.2 (which defaults to use C98), and I wonder whether g++ 4.1.2 guarantees that everything happens before (e.g. write to a variable) will be reflected in another thread if:
>> 1. there is no lock (e.g. pthread_mutex/spinlock) involving
>> 2. the "another thread" is created (e.g. calling pthread_create) after the "write"
>
> The relevant question for the compiler is whether it will issue all
> writes to globally visible memory before calling pthread_create.  The
> answer is: yes, it will.
>
> The rest is up to your library.  I would expect that any pthread library
> would have a memory barrier during pthread_create, in which case you
> should be fine.
>
> Ian

Re: Sequenced-Before for g++ 4.1.2?

[Ian Lance Taylor]

Hei Chan <structurechart@yahoo.com> writes:

> I probably misinterpreted what you meant about "globally visible
> memory".  I thought you meant that all threads would see the same
> copy.  What does "globally visible memory" refer to?

Yes, sorry, that was kind of ambiguous.  When I wrote "globally visible
memory" I meant a global variable or a memory location to which a global
variable points, perhaps indirectly.  E.g., if g is a global variable,
then g[1]->p1->p2 counts as globally visible.

Ian