On 19.12.2011 17:25, Tom Lane wrote:
Heikki Linnakangas writes:
On 19.12.2011 16:31, Robert Haas wrote:
Actually, I believe our Itanium (and possibly ARM, too) implementation
of S_UNLOCK() is wrong as it is.
Hmm. Anybody got a large itanium box we could play with? If it is
wrong, I'd expect
On 19.12.2011 17:39, Martin Pitt wrote:
Heikki Linnakangas [2011-12-19 17:09 +0200]:
One thing that caught my eye: if you use __sync_lock_and_test() to
implement S_LOCK(), you really should be using __sync_lock_release()
for S_UNLOCK().
Right, the patch I send does that:
#define S_UNLOCK(lo
Tom Lane [2011-12-19 10:25 -0500]:
> Heikki Linnakangas writes:
> > On 19.12.2011 16:31, Robert Haas wrote:
> >> On Sun, Dec 18, 2011 at 5:42 PM, Martin Pitt wrote:
> >>> I agree. How about a patch like this? It uses builtin atomics if
> >>> available, and falls back to the custom implementations
Heikki Linnakangas [2011-12-19 17:09 +0200]:
> One thing that caught my eye: if you use __sync_lock_and_test() to
> implement S_LOCK(), you really should be using __sync_lock_release()
> for S_UNLOCK().
Right, the patch I send does that:
#define S_UNLOCK(lock) __sync_lock_release(lock)
Martin
-
Robert Haas [2011-12-19 9:31 -0500]:
> On Sun, Dec 18, 2011 at 5:42 PM, Martin Pitt wrote:
> >> It probably makes sense to use it on any platform where it's
> >> defined. Presumably an implementation provided by the compiler is
> >> always going to be at least as good as any magic assembler
> >>
Heikki Linnakangas writes:
> On 19.12.2011 16:31, Robert Haas wrote:
>> On Sun, Dec 18, 2011 at 5:42 PM, Martin Pitt wrote:
>>> I agree. How about a patch like this? It uses builtin atomics if
>>> available, and falls back to the custom implementations if not.
>> -1. Absent some evidence that g
On 19.12.2011 16:31, Robert Haas wrote:
On Sun, Dec 18, 2011 at 5:42 PM, Martin Pitt wrote:
It probably makes sense to use it on any platform where it's
defined. Presumably an implementation provided by the compiler is
always going to be at least as good as any magic assembler
incantations we c
On Sun, Dec 18, 2011 at 5:42 PM, Martin Pitt wrote:
>> It probably makes sense to use it on any platform where it's
>> defined. Presumably an implementation provided by the compiler is
>> always going to be at least as good as any magic assembler
>> incantations we can come up with.
>
> I agree. H
Hello all,
Heikki Linnakangas wrote:
> An even better approach would be to have a configure test for
> __sync_lock_test_and_set. A quick google search suggests that Intel
> C Compiler version >= 11.0 also supports __sync_lock_test_and_set,
> for example.
Right,
http://gcc.gnu.org/onlinedocs/gcc-4
