I did get lot more information on this from Sleepycat support team: ************************************************************************** The problem is that Berkeley DB does not include assembly language mutexes for the s390 architecture, and Linux POSIX 1003.1 pthread mutexes aren't sufficient for DB as they do not support locking between processes, only between threads in a single process.
If you're building a server application, that is, you don't care about locking between multiple processes, then future releases of Berkeley DB will allow you to use the --enable-posixmutexes option during your DB configuration to force enabling of the pthread mutex support. > Can you guide me here, if I need locking between multiple processes, > how can I go about achieving that? You would need to write some form of mutual exclusion that works for this architecture, likely using s/390 assembler. Of course, the Linux port to the s/390 already contains the mutexes, so you could probably find that code and modify it to work inside of the Berkeley DB library. > I am also trying to get some suggestions from a Linux/390 mailing list. > Can I quote your response there, Please? Sure, feel free. Various groups keep threatening to make Linux pthreads mutexes work between processes, but it hasn't happened yet. > Does windows or solaris support synchronization between processes? Yes, both Windows and Solaris support synchronization between processes. ************************************************************************** So my final question is there any known open source project to get locking between processes, achieved ? Thanks, Samy Rengasamy. -----Original Message----- From: Alan Cox [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 14, 2002 4:55 PM To: [EMAIL PROTECTED] Subject: Re: Berkeley DB 4.0.1 Config Error > During the configure process, I did get the following warning: > THREAD MUTEXES NOT AVAILABLE FOR THIS COMPILER/ARCHITECTURE > > I do believe Linux/390 does support multi-threading and hence mutexes > towards that. For performance the db libraries try and use architecture specific locking tricks. Ideally someone wants to write and submit an S/390 set unless thats already been done.
