Re: Freezing without write I/O
От | Ants Aasma |
---|---|
Тема | Re: Freezing without write I/O |
Дата | |
Msg-id | CA+CSw_vTr6NxV6p4hSe5LBO3fc9eJFYRHjTDPOmP68QxG48_DA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Freezing without write I/O (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: Freezing without write I/O
|
Список | pgsql-hackers |
On Thu, Sep 19, 2013 at 2:42 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: >> * switchFinishXmin and nextSwitchXid should probably be either volatile >> or have a compiler barrier between accessing shared memory and >> checking them. The compiler very well could optimize them away and >> access shmem all the time which could lead to weird results. > > Hmm, that would be a weird "optimization". Is that really legal for the > compiler to do? Better safe than sorry, I guess. C doesn't really have a multi-threaded memory model before C11, so the compiler makers have just made one up that suits them best. For unlocked memory reads the compiler is free to assume that no one else is accessing the variable, so yes that "optimization" would be legal according to their rules. I'm tackling similar issues in my patch. What I'm thinking is that we should change our existing supposedly atomic accesses to be more explicit and make the API compatible with C11 atomics[1]. For now I think the changes should be something like this: * Have separate typedefs for atomic variants of datatypes (I don't think we have a whole lot of them). With C11 atomics support,this would change to typedef _Atomic TransactionId AtomicTransactionId; * Require that pg_atomic_init(type, var, val) be used to init atomic variables. Initially it would just pass through to assignment,as all supported platforms can do 32bit atomic ops. C11 compatible compilers will delegate to atomic_init(). * Create atomic read and write macros that look something like: #define pg_atomic_load(type, var) (*((volatile type*) &(var))) and #define pg_atomic_store(type, var, val) do { \ *((volatile type*) &(var)) = (val); \ } while(0) C11 would pass through to the compilers implementation with relaxed memory ordering. * Rename pg_read_barrier()/pg_write_barrier()/pg_memory_barrier() to pg_acquire_fence()/pg_release_fence()/pg_acq_rel_fence().Herb Sutter makes a convincing argument why loosening up the barriersemantics is the sane choice here. [2] C11 support can then pass though to atomic_thread_fence(). This way we have a relatively future proof baseline for lockfree programming, with options to expand with other primitives. We could also only do the volatile access macros part, at least it would make the intention more clear than the current approach of sprinkling around volatile pointers. Regards, Ants Aasma [1] http://en.cppreference.com/w/c/atomic [2] (long video about atomics) http://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Herb-Sutter-atomic-Weapons-1-of-2 -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de
В списке pgsql-hackers по дате отправления: