Re: Sequenced-Before for g++ 4.1.2?
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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@xxxxxxxxxx> To: Hei Chan <structurechart@xxxxxxxxx> Cc: "gcc-help@xxxxxxxxxxx" <gcc-help@xxxxxxxxxxx> Sent: Monday, April 16, 2012 9:33 AM Subject: Re: Sequenced-Before for g++ 4.1.2? Hei Chan <structurechart@xxxxxxxxx> 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@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