I disagree with this assessment. I believe the second call to SysVreateMutexSem should fail because the semaphore already exists. The second script should be using SysOpenMutexSem to get access to the existing semaphore.
I believe that the Windows version of this would cause the second script to fail because the semaphore already exists. Mark, Rick - please try this out on Windows and let me know if I am correct. If I am correct the fix should be to remove the sem_unlink() call in the *nix version of Rexxutil. David Ashley On Fri, 2012-10-26 at 09:07 +0200, Manfred Lotz wrote: > Hi there, > I think I have found an error in the mutex routines in Rexxutils under > Linux. > > > Rexx is: Open Object Rexx Version 4.1.1, Build date: May 21 > 2012, Addressing Mode: 32 > > > To show the error I created a small script like this: > > /* REXX */ > > sem = "Sem_A" > > hdl = SysCreateMutexSem(sem) > > if hdl = "" then do > Say "Couldn't create mutex" > hdl = SysOpenMutexSem(sem) > if hdl = 0 then do > Say "Error opening mutex "sem > exit 8 > end > end > > Say "Mutex handle :"hdl > > > > rc = SysRequestMutexSem(hdl,1) > say "Obained mutex: RC = "rc > > pull > > rc = SysReleaseMutexSem(hdl) > say "ReleaseMutex: RC = "rc > > rc = SysCloseMutexSem(hdl) > say "CloseMutex: RC = "rc > > > > When I start the script it grabs the mutex Sem_A and waits. Now when > starting the script a second time in another shell window > SysCreateMutexSem succeeds which is wrong as the mutex Sem_A does > already exist. > > The documentation supports my view: " If you specify name, > SysCreateMutexSem opens the semaphore if the mutex has already been > created." > > Having looked into rexxutil.cpp I found that in SysCreateMutexSem a > sem_unlink will be performed for a named pipe. > > Please observe that the semaphore semantics are different in Linux > than in Windows. > > > What happens in our test case when in SysCreateMutexSem the first thing > is a sem_unlink? > > The first called rexx script waits after it has gotten the mutex Sem_A. > Now the rexx is called again and in SysCreateMutexSem the call to > sem_unlink leads to the removal of the name Sem_A. The mutex itself > still exists and will die when the first called script stops. > > The second called script which is in SysCreatMutexSem now creates a new > mutex with name Sem_A, and thus is able to obtain the mutex. > > > What do you thin? > > ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
