Re: sinval synchronization considered harmful
От | Robert Haas |
---|---|
Тема | Re: sinval synchronization considered harmful |
Дата | |
Msg-id | CA+TgmobOy=+6Gp9v3JnGyVs0Fi1WUeM9dU5+bC3sN7J0Z_v9-Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: sinval synchronization considered harmful (Dan Ports <drkp@csail.mit.edu>) |
Список | pgsql-hackers |
On Thu, Jul 21, 2011 at 6:44 PM, Dan Ports <drkp@csail.mit.edu> wrote: > If you're suggesting that hardware memory barriers aren't going to be > needed to implement lock-free code on x86, that isn't true. Because a > read can be reordered with respect to a write to a different memory > location, you can still have problems. So you do still need memory > barriers, just fewer of them. > > Dekker's algorithm is the classic example: two threads each set a flag > and then check whether the other thread's flag is set. In any > sequential execution, at least one should see the other's flag set, but > on the x86 that doesn't always happen. One thread's read might be > reordered before its write. In the case of sinval, what we need to do for SIGetDataEntries() is, approximately, a bunch of loads, followed by a store to one of the locations we loaded (which no one else can have written meanwhile). So I think that's OK. In SIInsertDataEntries(), what we need to do is, approximately, take a lwlock, load from a location which can only be written while holding the lwlock, do a bunch of stores, ending with a store to that first location, and release the lwlock. I think that's OK, too. >> 2. Machines with weak memory ordering. On this category of machines >> (which includes PowerPC, Dec Alpha, and maybe some others), the CPU >> reorders memory accesses arbitrarily unless you explicitly issue >> instructions that enforce synchronization. You still need to keep the >> compiler from moving things around, too. Alpha is particularly >> pernicious, because something like a->b can fetch the pointed-to value >> before loading the pointer itself. This is otherwise known as "we >> have basically no cache coherency circuits on this chip at all". On >> these machines, you need to issue an explicit memory barrier >> instruction at each sequence point, or just acquire and release a >> spinlock. > > The Alpha is pretty much unique (thankfully!) in allowing dependent > reads to be reordered. That makes it even weaker than the typical > weak-ordering machine. Since reading a pointer and then dereferencing > it is a pretty reasonable thing to do regularly in RCU code, you > probably don't want to emit barriers in between on architectures where > it's not actually necessary. That argues for another operation that's > defined to be a barrier (mb) on the Alpha but a no-op elsewhere. > Certainly the Linux kernel found it useful to do so > (read_barrier_depends) > > Alternatively, one might question how important it is to support the > Alpha these days... Well, currently, we do, so we probably don't want to drop support for that without some careful thought. I searched the archive and found someone trying to compile 8.3.something on Alpha just a few years ago, so it's apparently not totally dead yet. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: