Date: Mon, 18 Jun 2007 12:34:13 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: current@freebsd.org Subject: Is someone aware of problem with SytemV semaphores? Message-ID: <20070618123413.3xh05qfuo0kk4ww4@webmail.leidinger.net>
next in thread | raw e-mail | index | archive | help
Hi,
a friend works on a benchmark program for IPC. One kind of IPC he =20
tries is SystemV shm. He uses SystemV semaphores to build mutexes and =20
condition variables for process synchronisation. He had a problem with =20
it and I agreed to have a look at it.
The program is now in a state where I don't know why it is not =20
behaving as it is supposed to be. What is does:
- 2 processes, one generating messages, one consuming messages
- both lock a queue in shm (mutex via sysv-semaphore) when accessing it
- there is some signaling (via sysv-semaphore) in the edge cases
(queue full -> producer wants to add -> queue gets not full anymore,
and similar for the reading but empty case).
The problem is, at some point some semaphores which can only be 0 or 1 =20
(other values are ruled out, as there are only increases by one or =20
decreases by one and it is not increased if it is already 1) have a =20
value of 2.
As a workaround he switched to setting the value (semvcl with SETVAL) =20
instead of doing a semop with +1. This seems to work so far, but =20
doesn't explain why we see this strange behavior.
I tested this on -current with gcc 4.2. The test program is available =20
on request.
Bye,
Alexander.
--=20
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070618123413.3xh05qfuo0kk4ww4>