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@xxxxxxxxxx> To: Hei Chan <structurechart@xxxxxxxxx> Cc: "gcc-help@xxxxxxxxxxx" <gcc-help@xxxxxxxxxxx> Sent: Friday, April 13, 2012 10:46 PM Subject: Re: Sequenced-Before for g++ 4.1.2? Hei Chan <structurechart@xxxxxxxxx> 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
