Skip site navigation (1) Skip section navigation (2)

Re: [PATCH] Use CC atomic builtins if available [was: Re: TAS patch for building on armel/armhf thumb]

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: [PATCH] Use CC atomic builtins if available [was: Re: TAS patch for building on armel/armhf thumb]
Date: 2011-12-19 15:09:11
Message-ID: 4EEF5397.8090200@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-bugs
On 19.12.2011 16:31, Robert Haas wrote:
> On Sun, Dec 18, 2011 at 5:42 PM, Martin Pitt<mpitt(at)debian(dot)org>  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. 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 gcc's implementations are superior to
> ours, I think we should not change stuff that works now.  That's
> likely to lead to subtle bugs that are hard to find and perhaps
> dependent on the exact compiler version used.

Ok, we're in disagreement on that then. I don't feel very strongly about 
it, let's see what others think.

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().

Actually, I believe our Itanium (and possibly ARM, too) implementation 
of S_UNLOCK() is wrong as it is. There is no platform-specific 
S_UNLOCK() defined for Itanium, so we're using the generic implementation:

#if !defined(S_UNLOCK)
#define S_UNLOCK(lock)		(*((volatile slock_t *) (lock)) = 0)
#endif	 /* S_UNLOCK */

That is not sufficient on platforms with a weak memory model, like Itanium.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-bugs by date

Next:From: Andrea GrassiDate: 2011-12-19 15:14:13
Subject: R: R: BUG #6342: libpq blocks forever in "poll" function
Previous:From: alexander.fortinDate: 2011-12-19 15:06:31
Subject: BUG #6347: Reopening bug #6085

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group