Re: thread_test.c problems

From: joseph speigle <joe(dot)speigle(at)jklh(dot)us>
To: PostgreSQL <pgsql-general(at)postgresql(dot)org>
Subject: Re: thread_test.c problems
Date: 2004-04-04 06:33:49
Message-ID: 20040404063349.GA28745@www.sirfsup.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

wespvp,

have you tried adding a volatile keyword to the

int volatile errno1_set = 0;
int volatile errno2_set = 0;

that should stop while-loop optimizing for cases where the variable is modified in a scope the compiler would be ignorant of, and precludes compiler while-loop optimization. That would then tell you if it was a while loop optimization problem.

As for me on RH 8.0

gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --host=i386-redhat-linux --with-system-zlib --enable-__cxa_atexit
Thread model: posix
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

sorry, they all run yes/no/no

On Sat, Apr 03, 2004 at 03:40:01PM -0600, wespvp(at)syntegra(dot)com wrote:
> [Sorry, I hit the wrong butt on and sent this earlier before I meant to]
>
> When I try to run thread_test.c from the CVS tip, it hangs in an infinite
> CPU loop on both linux (RedHat AS 3.0, gcc 3.2.3) and Mac OS X 10.3.3 (gcc
> 3.3). I've also tried down to gcc 2.96 on Mac OS X.
>
> If I compile it with -g instead of -O2 on linux, it runs to completion and
> gives me:
>
> Add this to your template/$port file:
>
> STRERROR_THREADSAFE=yes
> GETPWUID_THREADSAFE=no
> GETHOSTBYNAME_THREADSAFE=no
>
> On Mac OS X, it gives me:
>
> Add this to your template/$port file:
>
> STRERROR_THREADSAFE=yes
> GETPWUID_THREADSAFE=yes
> GETHOSTBYNAME_THREADSAFE=yes
>
> If I modify the two while loops
>
> while (errno2_set == 0)
>
> while (errno1_set == 0)
>
> To execute a 'print' statement or a 'time(NULL)' instead of a null loop,
> then it runs to completion with -O2.
>
>
>
> If I run the 7.4.2 released version of thread_test.c, for both platforms I
> get:
>
> Add this to your template/$port file:
>
> NEED_REENTRANT_FUNCS=yes
>
> There seems to be two problems
>
> 1. It would appear the compiler is optimizing the while loop to be an
> infinite loop. Other explanations?
>
> 2. The answers both can't be right... On OS X, the 7.4.2 version says
> NEED_REENTRANT_FUNCS=yes, but with the tip version it says all are thread
> safe.
>
>
>
> On linux, the make run (putting 'time(NULL)' in the loop):
>
> make
> gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
> -Wmissing-declarations -D_REENTRANT -D_THREAD_SAFE
> -D_POSIX_PTHREAD_SEMANTICS -I../../../src/include -D_GNU_SOURCE -c -o
> thread_test.o thread_test.c -MMD
> gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
> -Wmissing-declarations -D_REENTRANT -D_THREAD_SAFE
> -D_POSIX_PTHREAD_SEMANTICS -L../../../src/port
> -Wl,-rpath,/wdisk/wrp/opensrc/as30/local/pgsql7.4.2/lib -lpthread
> thread_test.o -lz -lcrypt -lresolv -lnsl -ldl -lm -lbsd -lpgport -o
> thread_test
> [wrp(at)juniper thread]$ !.
> ./thread_test
> Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'
> defines to your template/$port file before compiling this program.
>
> Add this to your template/$port file:
>
> STRERROR_THREADSAFE=yes
> GETPWUID_THREADSAFE=no
> GETHOSTBYNAME_THREADSAFE=no
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)

--
joe speigle
www.sirfsup.com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Mooney, Ryan 2004-04-04 06:39:31 Re: Large DB
Previous Message Tom Lane 2004-04-04 05:44:13 Re: Recursive FOREIGN KEY?

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2004-04-04 07:51:59 Re: Function to kill backend
Previous Message Mike Mascari 2004-04-04 06:04:32 Re: Function to kill backend