Re: Problem with locks

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>>> Seems to me this proves nothing much, since it doesn't use the same SysV
>>> semaphore API PG does.
>
>> I was trying to copy the semaphore API exactly assuming
>> USE_NAMED_POSIX_SEMAPHORES was *not* defined. According to the comments we
>> prefer not to use named semaphores if possible.
>
> What you seem to have copied is the posix_sema.c code, which AFAIK is
> only used on Darwin. sysv_sema.c is what to look at ... unless your
> benchmark machine is a Mac.

I switched the code over to the sysv_sema style api. It's gotten a bit grotty
and I would clean it up if it weren't a temporary test program. If we find a
real problem perhaps I should add a test case like this to the "smoke test" in
ipc_test.c so people can check their OS.

I did add something like the setitimer deadlock timeout to detect a process
stuck waiting. There is a race condition there if a process is woken up just
as the timer fires but if the timeout is large enough the chances of that are
pretty remote. Judging by the first thread the whole loop excluding the usleep
takes about 3ms. I've been using a timeout of 10 seconds. As such:

$ ./a.out 40 900 10
running with 40 processes for 900s with timeout of 10000ms
telling threads to exit
run done
cleaning up semaphores and shared memory