Re: Are SysV semaphores thread-safe on CURRENT?

2002-11-30 Thread Brian Smith
On Mon, 18 Nov 2002 22:05:34 -0800, Terry Lambert wrote: Use mmap of a backing-store file, and then use file locking to do record locking in the shared memory segment. Ok, I did this, and it actually works considerably better than the SysV shared memory. However flock() has the same problem as

Re: Are SysV semaphores thread-safe on CURRENT?

2002-11-30 Thread Daniel Eischen
On Sat, 30 Nov 2002, Brian Smith wrote: On Mon, 18 Nov 2002 22:05:34 -0800, Terry Lambert wrote: Use mmap of a backing-store file, and then use file locking to do record locking in the shared memory segment. Ok, I did this, and it actually works considerably better than the SysV shared

Re: Are SysV semaphores thread-safe on CURRENT?

2002-11-30 Thread Daniel Eischen
On Sat, 30 Nov 2002, Daniel Eischen wrote: On Sat, 30 Nov 2002, Brian Smith wrote: On Mon, 18 Nov 2002 22:05:34 -0800, Terry Lambert wrote: Use mmap of a backing-store file, and then use file locking to do record locking in the shared memory segment. Ok, I did this, and it

Re: Are SysV semaphores thread-safe on CURRENT?

2002-11-30 Thread Terry Lambert
Brian Smith wrote: On Mon, 18 Nov 2002 22:05:34 -0800, Terry Lambert wrote: Use mmap of a backing-store file, and then use file locking to do record locking in the shared memory segment. Ok, I did this, and it actually works considerably better than the SysV shared memory. However flock()

Re: Are SysV semaphores thread-safe on CURRENT?

2002-11-30 Thread Terry Lambert
Daniel Eischen wrote: No, libc_r doesn't properly handle flock. Usually, all syscalls that take file descriptors as arguments honor the non-blocking mode of the file if set. I guess flock(2) doesn't and has its own option to the operation argument (LOCK_NB). I hacked libc_r to

Are SysV semaphores thread-safe on CURRENT?

2002-11-18 Thread Brian Smith
I've been porting an application from Linux to FreeBSD using STABLE, and it appears from looking at the semaphore code that the SysV semaphores are not thread safe on STABLE. I don't have CURRENT source code to look at currently. Does anyone know if they are thread-safe in CURRENT? Thanks!

Re: Are SysV semaphores thread-safe on CURRENT?

2002-11-18 Thread Daniel Eischen
On Mon, 18 Nov 2002, Brian Smith wrote: I've been porting an application from Linux to FreeBSD using STABLE, and it appears from looking at the semaphore code that the SysV semaphores are not thread safe on STABLE. I don't have CURRENT source code to look at currently. Does anyone know

Re: Are SysV semaphores thread-safe on CURRENT?

2002-11-18 Thread Brian Smith
On Mon, 18 Nov 2002 21:33:38 -0500 (EST), Daniel Eischen wrote: [ I assume you mean semop, semctl, not sema_* or sem_* ] Yes ... semop() specifically is causing the problems... Sure SysV semaphores are thread-safe. When a thread blocks on one, the entire process blocks (no threads run). You

Re: Are SysV semaphores thread-safe on CURRENT?

2002-11-18 Thread Garrett Wollman
On Mon, 18 Nov 2002 22:31:28 -0600, Brian Smith [EMAIL PROTECTED] said: Is this the recommended method of preventing these problems? The recommended method of preventing these problems generally is to use POSIX semaphores (or other POSIX synchronization mechanisms appropriate to threaded

Re: Are SysV semaphores thread-safe on CURRENT?

2002-11-18 Thread Terry Lambert
Brian Smith wrote: Sure SysV semaphores are thread-safe. When a thread blocks on one, the entire process blocks (no threads run). You won't get any safer than that ;-) Yikes that isn't good. Is that only in STABLE? or does CURRENT do that as well? I guess I'll have to protect the