Re: Sequenced-Before for g++ 4.1.2?

[Hei Chan <structurechart@yahoo.com>]

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