Subj : Re: Memory synchronization with pthreads To : comp.programming.threads From : Joseph Seigh Date : Tue Jan 18 2005 07:40 am On Tue, 18 Jan 2005 10:18:47 +0100, Alexander Terekhov wrote: > > Joseph Seigh wrote: > [...] >> > It does not say "if you registered an at fork handler with pthread_atfork() >> > AND the handler invoked pthread functions that synchronized memory". >> >> fork shouldn't be in that list. > > Wrong. In release consistency speak, fork() has "release->acquire" > msync semantics with respect to the calling thread and the initial > thread in the created process. The fact that the copy "is made" > (COW aside for a moment) is pretty much irrelevant. > release/acquire only has meaning for shared memory. The forked process doesn't share memory. You're reading into the spec something that's not there. Now there's memory synchronization when you communicate from one thread to another when the data is copied to and from data buffers but I don't think they're all listed as memory synchronization functions, otherwise you'd see read, write, etc... in that list. I've been arguing that you can use these functions for that undocumented side effect. How safe is that? Well see if you could implememnt read, write, etc... without any synchronization on any of the platforms you are considering using. But all that aside, the memory synchronization done by fork isn't very exploitable. You might get "acquire" semantics from it but that's only because it's a syscall and you will get acquire and release semantics only because syscalls usually serialize the processor to protect the kernel from hardware errors from userspace occurring in the kernel. You could have used any syscall then and there a lot less expensive syscalls than fork. -- Joe Seigh .