Re: [Oorexx-devel] Mutex problem

[David A. <w.d...@gm...>]

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?
> 
>