#761 A too persistent mutex semaphore

v4.0
closed
nobody
5
2012-08-14
2009-07-14
No

I don't know how I got into this situation, but a particular mutex semaphore persists between invocations of Rexx. (Actually, there are two of them now).
Running the statement at the end of this note as a standalone program shows that it can be opened without being created.
There is no other Rexx process running on my machine.
I'm "certain" that no non-Rexx process knows about the semaphore.

Rexx is not running as a service.
If I run the statement below before killing RxApi.exe, it returns "000001B8".
If I then use Task Manager to kill RxApi.exe and then run the statement, it returns "000001C0".
If I then run the statement again several time, it again says "000001B8" each time.

I'm running REXX-ooRexx_4.0.0(MT) 6.03 30 Jun 2009 in an up to date Vista.

say SysOpenMutexSem('FILELOCK-C--WORKFILE-DAILY-FILES.UT4')

Discussion

  • Mark Miesfeld

    Mark Miesfeld - 2009-07-15

    Doug,

    I don't see this as an ooRexx bug. When you use the mutex or semaphore RexxUtils functions, the interpreter doesn't manage the mutexes or semaphores for you, you are responsible for doing that yourself.

    In addition, the operating system itself is in charge of destroying the mutex object. The operating system will destroy the mutex object when all open handles have been closed. If all opened handles are closed, and the operating system doesn't destroy the mutex object, then that is an operating system bug. There is no way for the interpreter to destroy the mutext object.

    Your say statement: say SysOpenMutexSem('FILELOCK-C--WORKFILE-DAILY-FILES.UT4')

    is equivalent to:

    hMutext = SysOpenMutexSem('FILELOCK-C--WORKFILE-DAILY-FILES.UT4')
    say 'hMutext:' hMutext

    The value displayed for a mutex handle is completely meaningless. This goes back to handles being opaque. When the operating system gives you a handle, that handle is suitable for use in functions that require a handle arguement. No matter what value is displayed, only the operating system knows exactly which mutex object it points to. There is nothing that says the operating system has to give out handles in different processes, to the same mutex object, with either different display values, or with the same display value.

    If you get back a good handle from SysOpenMutextSem() for a named mutex, then it came straight from the operating system and the operating system thinks it has an existing mutex object with that name.

     
  • Mark Miesfeld

    Mark Miesfeld - 2009-07-15

    Doug,

    I meant to add this, you say:

    There is no other Rexx process running on my machine.
    I'm "certain" that no non-Rexx process knows about the semaphore.

    The handle returned from SysOpenMutexSem() is inheritable. If you start any other process from the Rexx process that opened the handle, then depending on how the process is created it could inherit the handle.

     
  • Anonymous - 2009-07-15

    Yeah, it's hard to see how it can be ooRexx's bug since no rexx-related process was running (or is there such a process other than the Rexx.exe & RxApi.exe that I killed?). But it's also hard to see how it can be a Vista problem since I would think phantom mutexes would cause big problems elsewhere. Strange.

     
  • Anonymous - 2009-07-15

    Well, now I'm pretty sure it's not a ooRexx bug. I just uninstalled 4.0.0, went back to 3.2.0 and the mutex is still active!

     
  • David Ashley

    David Ashley - 2009-07-15

    Again, semaphore are managed by the operating system, not applications. Application perform semaphore operations by asking the OS to perform the operation on its behalf. Semaphore are persistent across invocations of the application. They have to be or Linux/Windows would be missing an important inter-process communication mechanism.

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks