Re: Freezing without write I/O
| От | didier |
|---|---|
| Тема | Re: Freezing without write I/O |
| Дата | |
| Msg-id | CAJRYxuL8RMmFs7H6+bA64tH-1_zUGJCwgYjcZEHM-rmmsgustg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Freezing without write I/O (Andres Freund <andres@2ndquadrant.com>) |
| Список | pgsql-hackers |
Hi,
IMO it's a bug if S_UNLOCK is a not a compiler barrier.https://www.securecoding.cert.org/confluence/display/seccode/DCL17-C.+Beware+of+miscompiled+volatile-qualified+variables
regards
Didier
On Fri, Sep 20, 2013 at 5:11 PM, Andres Freund <andres@2ndquadrant.com> wrote:
On 2013-09-20 16:47:24 +0200, Andres Freund wrote:From a quick look
> I think we should go through the various implementations and make sure
> they are actual compiler barriers and then change the documented policy.
* S_UNLOCK for PPC isn't a compiler barrier
* S_UNLOCK for MIPS isn't a compiler barrier
* I don't know enough about unixware (do we still support that as a
platform even) to judge
* True64 Alpha I have no clue about
* PA-RISCs tas() might not be a compiler barrier for !GCC
* PA-RISCs S_UNLOCK might not be a compiler barrier
* HP-UX !GCC might not
* IRIX 5 seems to be a compiler barrier
* SINIX - I don't care
* AIX PPC - compiler barrier
* Sun - TAS is implemented in external assembly, normal function call,
compiler barrier
* Win(32|64) - compiler barrier
* Generic S_UNLOCK *NOT* necessarily a compiler barrier.
Ok, so I might have been a bit too optimistic...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: