The short answer is that Windows does not have semaphore sets, so the number within the set is meaningless.
From the Progress perspective always "use" semaphores irrespective of the OS or if -spin locks are in use. The Article references below take this discussion further.
Although we use semaphores on Windows, these are internal semaphores which are entirely managed by the Windows OS and not exposed. Semaphores on Windows are only limited by the resource availability. Unlike on UNIX where these are limited by kernel settings.
On UNIX the semget() function (sys/sem.h) is used to get a set of semaphores and it returns a semaphore identifier. The information displayed by PROMON is the semaphore id returned by that function. On UNIX the semid returned by semget() is used as a parameter for other operations functions as well such as semop().
UNIX Example: promon > 1. User Control:
Usr Name Type Wait Table Dbkey Trans PID Sem Srv ...
0 uname1 BROK -- 0 0 0 1108 3 0
1 uname2 SERV -- 0 0 0 1309 8 0
5 uname3 SELF/ABL -- 0 0 0 2024 13 0
6 uname4 MON -- 0 0 0 1836 9 0
Windows also provides a semaphore object with similar functionality and is created using the createsemaphore() function but instead of returning a non-negative integer id, it returns a handle to the semaphore object and one of its functions parameters is the name of that object.
Windows has its own style of interprocess communication/system calls, the name or the handle can be used later in other semaphore related operations functions, so it would not help anything to have the information about that handle in PROMON.
WINDOWS Example: promon > 1. User Control:
Usr Name Type Wait Table Dbkey Trans PID Sem Srv ...
0 uname1 BROK -- 0 0 0 4464 0 0
1 uname2 SERV -- 0 0 0 5216 0 0
5 uname3 SELF/ABL -- 0 0 0 4780 0 0
6 uname4 MON -- 0 0 0 4928 0 0
|
