info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Problem with sem_open() call
717 views
Skip to first unread message
Alexander Saprykin
Sep 19, 2016, 9:19:07 AM9/19/16
to
I'm trying to use POSIX semaphores introduced in OpenVMS 8.4, but with no luck.
1. Calling sem_open("/myname", O_CREAT | O_EXCL, 0660, 1) returns a pointer to a semaphore structure (sem_t), no problems here.
2. Calling the same routine returns EEXIST on the second time, as described in manual (so, the semaphore already exists), no problems here.
3. But subsequent sem_open("/myname", 0) call fails with ENOENT error code which means that there is no semaphore with such a name. But semaphore actually exists, because even sem_unlink ("/myname") returns 0.
So I couldn't open semaphore after its creation.
Has some faced with such a problem? Maybe I need to make some system configuration changes?
Best Regards,
Alexander Saprykin
1. Calling sem_open("/myname", O_CREAT | O_EXCL, 0660, 1) returns a pointer to a semaphore structure (sem_t), no problems here.
2. Calling the same routine returns EEXIST on the second time, as described in manual (so, the semaphore already exists), no problems here.
3. But subsequent sem_open("/myname", 0) call fails with ENOENT error code which means that there is no semaphore with such a name. But semaphore actually exists, because even sem_unlink ("/myname") returns 0.
So I couldn't open semaphore after its creation.
Has some faced with such a problem? Maybe I need to make some system configuration changes?
Best Regards,
Alexander Saprykin
Stephen Hoffman
Sep 19, 2016, 11:12:54 AM9/19/16
to
point. Then please post a (small!) reproducer of the problem, and
post up the local definitions of the DECC* logical name morass, and
some folks here can use that to determine if it's OpenVMS, the local
system configuration, the source code involved. Or you can ring up
HPE support and ask them, if you have access to that path.
--
Pure Personal Opinion | HoffmanLabs LLC
Alexander Saprykin
Sep 21, 2016, 6:04:25 AM9/21/16
to
понедельник, 19 сентября 2016 г., 18:12:54 UTC+3 пользователь Stephen Hoffman написал:
Sorry for a delay, I have been preparing a clean OpenVMS install. I'm using FreeAXP emulator with a Hobbyist PAK. So the system is OpenVMS 8.4 from the HP's FTP, CC 7.3. I'm a novice with OpenVMS and I do not have a reach experience with it. I'm trying to port my personal project (system library). If you need any information (sorry, I do not understand what do you need with "local definitions of the DECC* logical name morass"), please write down a command I need to execute to post output here.
I have prepared several small programs to reproduce the behaviour.
The first program (I call it sem_create) creates a named (system-wide, global) semaphore:
#include <semaphore.h>
#include <stdio.h>
#include <errno.h>
int main ()
{
sem_t * my_semaphore;
my_semaphore = sem_open ("/mysemaphore", O_CREAT | O_EXCL, 0660, 0);
if (my_semaphore == SEM_FAILED) {
if (errno == EEXIST)
printf ("[OK] Semaphore exists\n");
else
printf ("[FAIL] Error code: %d\n", errno);
} else
printf ("[OK] Semaphore created\n");
return 0;
}
The second program (I call it sem_open) tries to open an existing named semaphore:
#include <semaphore.h>
#include <stdio.h>
#include <errno.h>
int main ()
{
sem_t * my_semaphore;
my_semaphore = sem_open ("/mysemaphore", 0);
if (my_semaphore == SEM_FAILED)
printf ("[FAIL] Error code: %d\n", errno);
else
printf ("[OK] Semaphore opened\n");
return 0;
}
The third program (I call it sem_unlink) removes the semaphore from the system:
#include <semaphore.h>
#include <stdio.h>
#include <errno.h>
int main ()
{
int rc;
rc = sem_unlink ("/mysemaphore");
if (rc != 0)
printf ("[FAIL] Error code: %d\n", errno);
else
printf ("[OK] Semaphore unlinked\n");
return 0;
}
To reproduce the problem:
1. Launch the sem_create program to create a semaphore.
2. Launch the sem_create program again to make sure that the semaphore actually exists now.
3. Launch the sem_open program to open the semaphore created before. Instead of success, you should receive a fail here. Which is a problem I faced: the semaphore exists, but I'm not able to open it.
4. To remove the semaphore launch the sem_unlink program. Note that it removes it successfully.
I'm stuck at this for now. As for possible updates and patches: I have ALPHA084LP1.ISO and ALPHA084LP2.ISO updates from VMS Software, also I have openvms_alpha_8_4_Update500.zip and OpenVMSAlphaV84-TCP57ECO5.zip patches, but I don't know if anything of this could help me. I do not have access for HP support :( I was also trying to reach someone from VMS Software via a contact email on their web-site, but no response.
I would greatly appreciate if someone with the latest (patched) VMS can confirm (or not) the problem described above.
Best Regards,
Alexander Saprykin
I have prepared several small programs to reproduce the behaviour.
The first program (I call it sem_create) creates a named (system-wide, global) semaphore:
#include <semaphore.h>
#include <stdio.h>
#include <errno.h>
int main ()
{
sem_t * my_semaphore;
my_semaphore = sem_open ("/mysemaphore", O_CREAT | O_EXCL, 0660, 0);
if (my_semaphore == SEM_FAILED) {
if (errno == EEXIST)
printf ("[OK] Semaphore exists\n");
else
printf ("[FAIL] Error code: %d\n", errno);
} else
printf ("[OK] Semaphore created\n");
return 0;
}
The second program (I call it sem_open) tries to open an existing named semaphore:
#include <semaphore.h>
#include <stdio.h>
#include <errno.h>
int main ()
{
sem_t * my_semaphore;
my_semaphore = sem_open ("/mysemaphore", 0);
if (my_semaphore == SEM_FAILED)
printf ("[FAIL] Error code: %d\n", errno);
else
printf ("[OK] Semaphore opened\n");
return 0;
}
The third program (I call it sem_unlink) removes the semaphore from the system:
#include <semaphore.h>
#include <stdio.h>
#include <errno.h>
int main ()
{
int rc;
rc = sem_unlink ("/mysemaphore");
if (rc != 0)
printf ("[FAIL] Error code: %d\n", errno);
else
printf ("[OK] Semaphore unlinked\n");
return 0;
}
To reproduce the problem:
1. Launch the sem_create program to create a semaphore.
2. Launch the sem_create program again to make sure that the semaphore actually exists now.
3. Launch the sem_open program to open the semaphore created before. Instead of success, you should receive a fail here. Which is a problem I faced: the semaphore exists, but I'm not able to open it.
4. To remove the semaphore launch the sem_unlink program. Note that it removes it successfully.
I'm stuck at this for now. As for possible updates and patches: I have ALPHA084LP1.ISO and ALPHA084LP2.ISO updates from VMS Software, also I have openvms_alpha_8_4_Update500.zip and OpenVMSAlphaV84-TCP57ECO5.zip patches, but I don't know if anything of this could help me. I do not have access for HP support :( I was also trying to reach someone from VMS Software via a contact email on their web-site, but no response.
I would greatly appreciate if someone with the latest (patched) VMS can confirm (or not) the problem described above.
Best Regards,
Alexander Saprykin
Eberhard Heuser
Sep 21, 2016, 6:45:04 AM9/21/16
to info...@rbnsn.com
Am 21.09.2016 um 12:04 schrieb Alexander Saprykin via Info-vax:
> #include <semaphore.h>
> #include <stdio.h>
> #include <errno.h>
>
> int main ()
> {
> int rc;
>
> rc = sem_unlink ("/mysemaphore");
>
> if (rc != 0)
> printf ("[FAIL] Error code: %d\n", errno);
> else
> printf ("[OK] Semaphore unlinked\n");
>
> return 0;
> }
$ r sem_create
> #include <semaphore.h>
> #include <stdio.h>
> #include <errno.h>
>
> int main ()
> {
> int rc;
>
> rc = sem_unlink ("/mysemaphore");
>
> if (rc != 0)
> printf ("[FAIL] Error code: %d\n", errno);
> else
> printf ("[OK] Semaphore unlinked\n");
>
> return 0;
> }
[OK] Semaphore created
$ r sem_open
[FAIL] Error code: 2
$ r sem_remove
[OK] Semaphore unlinked
OVMS V8.4-1H1 ; VSI C V7.4-001
Eberhard
Stephen Hoffman
Sep 21, 2016, 1:01:37 PM9/21/16
to
On 2016-09-21 10:04:16 +0000, Alexander Saprykin said:
> Sorry for a delay, I have been preparing a clean OpenVMS install. I'm
> using FreeAXP emulator with a Hobbyist PAK. So the system is OpenVMS
> 8.4 from the HP's FTP, CC 7.3. I'm a novice with OpenVMS and I do not
> have a reach experience with it. I'm trying to port my personal project
> (system library). If you need any information (sorry, I do not
> understand what do you need with "local definitions of the DECC*
> logical name morass"), please write down a command I need to execute to
> post output here.
>
> I have prepared several small programs to reproduce the behaviour.
I suspect you've found a bug in the OpenVMS V8.4 implementation of the
> Sorry for a delay, I have been preparing a clean OpenVMS install. I'm
> using FreeAXP emulator with a Hobbyist PAK. So the system is OpenVMS
> 8.4 from the HP's FTP, CC 7.3. I'm a novice with OpenVMS and I do not
> have a reach experience with it. I'm trying to port my personal project
> (system library). If you need any information (sorry, I do not
> understand what do you need with "local definitions of the DECC*
> logical name morass"), please write down a command I need to execute to
> post output here.
>
> I have prepared several small programs to reproduce the behaviour.
sem_open call.
This tested with the following configuration:
$ cc/vers
HP C V7.3-010 on OpenVMS Alpha V8.4
running on Alpha hardware, and with VMS84A_UPDATE V10.0 and most of the
rest of the "recent" patches loaded. (I've not gone looking for any
particular patches that might address this.)
As for the "morass": DEC/Compaq/HP/HPE C has more than a score of
compatibility settings controlled by out-of-sight and out-of-band
DECC$* logical names, and these settings can and do change run-time
behaviors. http://labs.hoffmanlabs.com/node/1513 That written and
given the C code shown here, I don't expect that this particular
"morass" of settings is involved in this case. This looks like a
straight up bug in the library.
Alexander Saprykin
Sep 21, 2016, 1:20:53 PM9/21/16
to
среда, 21 сентября 2016 г., 20:01:37 UTC+3 пользователь Stephen Hoffman написал:
Are here in the group any developers from the VMS Software to check it in the VMS source? I don't know whom to contact to clarify this issue. I still unsure if it is a bug or not, maybe underlying (I guess) Distributed Lock Manager need to be configured or something else.
I mean it is a primary use case of the POSIX named semaphores, I do not believe they released a new API without testing it. If it is a bug, it can affect lot of other software which can be potentially ported on OpenVMS.
Best Regards,
Alexander Saprykin
I mean it is a primary use case of the POSIX named semaphores, I do not believe they released a new API without testing it. If it is a bug, it can affect lot of other software which can be potentially ported on OpenVMS.
Best Regards,
Alexander Saprykin
Stephen Hoffman
Sep 21, 2016, 1:48:23 PM9/21/16
to
On 2016-09-21 17:20:51 +0000, Alexander Saprykin said:
> Are here in the group any developers from the VMS Software to check it
> in the VMS source? I don't know whom to contact to clarify this issue.
> I still unsure if it is a bug or not, maybe underlying (I guess)
> Distributed Lock Manager need to be configured or something else.
Folks from VSI do follow this newsgroup. They will probably see this
> Are here in the group any developers from the VMS Software to check it
> in the VMS source? I don't know whom to contact to clarify this issue.
> I still unsure if it is a bug or not, maybe underlying (I guess)
> Distributed Lock Manager need to be configured or something else.
thread. As for HPE, you'd have to have somebody with a support
contract log a call. Same path (officially) for reporting bugs and
requesting fixes from VSI, too.
> I mean it is a primary use case of the POSIX named semaphores, I do not
> believe they released a new API without testing it. If it is a bug, it
> can affect lot of other software which can be potentially ported on
> OpenVMS.
that's with fairly recent OpenVMS Alpha running on a supported Alpha
box. Which usually means there's a bug in the code, and a gap in the
testing. OpenVMS has had its share of bugs over the years, as have
other platforms.
John Reagan
Sep 21, 2016, 1:56:16 PM9/21/16
to
$ type sem_create.c
#include <semaphore.h>
#include <stdio.h>
#include <errno.h>
int main ()
{
sem_t * my_semaphore;
my_semaphore = sem_open ("/mysemaphore", O_CREAT | O_EXCL, 0660, 0);
if (my_semaphore == SEM_FAILED) {
if (errno == EEXIST)
printf ("[OK] Semaphore exists\n");
else if (errno == EVMSERR)
#include <stdio.h>
#include <errno.h>
int main ()
{
sem_t * my_semaphore;
my_semaphore = sem_open ("/mysemaphore", O_CREAT | O_EXCL, 0660, 0);
if (my_semaphore == SEM_FAILED) {
if (errno == EEXIST)
printf ("[OK] Semaphore exists\n");
printf ("[FAIL] VMS Error code: %d\n", vaxc$errno);
else
printf ("[FAIL] Error code: %d\n", errno);
} else
printf ("[OK] Semaphore created\n");
return 0;
}
$ r sem_create
printf ("[FAIL] Error code: %d\n", errno);
} else
printf ("[OK] Semaphore created\n");
return 0;
}
[FAIL] VMS Error code: 98962
$ exit 98962
%RMS-E-FNF, file not found
Stephen Hoffman
Sep 21, 2016, 2:11:11 PM9/21/16
to
On 2016-09-21 17:56:14 +0000, John Reagan said:
> I hadn't used these before... and I must be doing something wrong...
> What file isn't being found?
On little evidence beyond the XQP trace, I might suspect the sem_open
> I hadn't used these before... and I must be doing something wrong...
> What file isn't being found?
is getting confused about the lack of flags.
The "file" specified here intended to be functionally analogous to an
OpenVMS lock manager resource name.
The underlying semaphore may or may not be implemented as a file.
OpenVMS pretty clearly uses a file, though. (Not sure why, given the
availability of the DLM, but...)
Quoth the The Open Group Base Specifications IEEE Std 1003.1, 2004 edition:
"The name argument points to a string naming a semaphore object. It is
unspecified whether the name appears in the file system and is visible
to functions that take pathnames as arguments. The name argument
conforms to the construction rules for a pathname. If name begins with
the slash character, then processes calling sem_open() with the same
value of name shall refer to the same semaphore object, as long as that
name has not been removed. If name does not begin with the slash
character, the effect is implementation-defined. The interpretation of
slash characters other than the leading slash character in name is
implementation-defined."
$ set watch/class=major file
$ r sem_create
%XQP, Thread #0, Access sem_create.EXE;3 (150467,3,0) Status: 00000001
%XQP, Thread #0, Lookup (161067,1,0) Status: 00000001
%XQP, Thread #0, Access DECC$SHRP.EXE;1 (161067,1,0) Status: 00000001
%XQP, Thread #0, Control function (161067,1,0) Status: 00000001
%XQP, Thread #0, Deaccess (161067,1,0) Reads: 2, Writes: 0, Status: 00000001
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup PSX$SEMAPHORES.DIR;1 (6895,15,0) Status: 00000001
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Access (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup PSX$SEMAPHORES.DIR;1 (6895,15,0) Status: 00000001
%XQP, Thread #0, Access PSX$SEMAPHORES.DIR;1 (6895,15,0) Status: 00000001
%XQP, Thread #0, Deaccess (6895,15,0) Reads: 0, Writes: 0, Status: 00000001
%XQP, Thread #0, Lookup PSX$SEMAPHORES.DIR;1 (6895,15,0) Status: 00000001
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Access (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Access (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Create/Access mysemaphore.;1 (6943,959,0) Status: 00000001
%XQP, Thread #0, Control function (6943,959,0) Status: 00000001
%XQP, Thread #0, Final status: 00000870
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (6943,959,0) Status: 00000001
%XQP, Thread #0, Access mysemaphore.;1 (6943,959,0) Status: 00000800
%XQP, Thread #0, Lookup mysemaphore.;1 (6943,959,0) Status: 00000001
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Access EASTERN.;1 (852,5,0) Status: 00000001
%XQP, Thread #0, Control function (852,5,0) Status: 00000001
%XQP, Thread #0, Final status: 00000870
%XQP, Thread #0, Deaccess (852,5,0) Reads: 1, Writes: 0, Status: 00000001
%XQP, Thread #0, Modify mysemaphore.;1 (6943,959,0) Status: 00000001
%XQP, Thread #0, Deaccess (6943,959,0) Reads: 1, Writes: 2, Status: 00000001
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Access mysemaphore.;1 (6943,959,0) Status: 00000001
%XQP, Thread #0, Control function (6943,959,0) Status: 00000001
[OK] Semaphore created
%XQP, Thread #0, Deaccess (6943,959,0) Reads: 0, Writes: 0, Status: 00000001
%XQP, Thread #0, Deaccess (150467,3,0) Reads: 5, Writes: 0, Status: 00000001
$ r sem_open
%XQP, Thread #0, Access sem_open.EXE;3 (150468,3,0) Status: 00000001
[FAIL] Error code: 2
%XQP, Thread #0, Deaccess (150468,3,0) Reads: 5, Writes: 0, Status: 00000001
$
Stephen Hoffman
Sep 21, 2016, 2:14:17 PM9/21/16
to
On 2016-09-21 18:11:08 +0000, Stephen Hoffman said:
> %XQP, Thread #0, Lookup (0,0,0) Status: 00000910
ps: all those 910 ("%SYSTEM-W-NOSUCHFILE, no such file") status returns
> %XQP, Thread #0, Lookup (0,0,0) Status: 00000910
don't make this particular code look particularly healthy...
John Reagan
Sep 21, 2016, 2:37:30 PM9/21/16
to
As for all the 910s, I'll add it to my list to try to hunt those down.
John Reagan
Sep 21, 2016, 3:02:34 PM9/21/16
to
Stephen Hoffman
Sep 21, 2016, 4:11:30 PM9/21/16
to
On 2016-09-21 19:02:33 +0000, John Reagan said:
> Ok, after I found a system with a valid PSX$SEMAPHORES directory (that
> seems to be another bug with the upgrade files), I was able to get the
> same failure with sem_open() on a V8.4-2 system. I'll add it to the
> list...
VMSINSTAL.XML was intended to help spot those bugs, and file
> Ok, after I found a system with a valid PSX$SEMAPHORES directory (that
> seems to be another bug with the upgrade files), I was able to get the
> same failure with sem_open() on a V8.4-2 system. I'll add it to the
> list...
corruptions or other untoward modifications, as well as its existing
use in kitting, but that work was never completed.
Alexander Saprykin
Sep 21, 2016, 4:59:08 PM9/21/16
to
среда, 21 сентября 2016 г., 22:02:34 UTC+3 пользователь John Reagan написал:
Just curious: where can I find that PSX$SEMAPHORES directory?
hb
Sep 21, 2016, 5:11:45 PM9/21/16
to
On 09/21/2016 10:59 PM, Alexander Saprykin wrote:
> Just curious: where can I find that PSX$SEMAPHORES directory?
in SYS$SPECIFIC:[000000]
> Just curious: where can I find that PSX$SEMAPHORES directory?
William Cox
Oct 15, 2023, 3:18:39 PM10/15/23
to
So it's been seven years since this was posted. I just tried the sample programs on x86_64 V9.2-1 and it still looks like the same problem exists. I can see the semaphore file in the PSX$SEMAPHORES directory, but the open fails.
Is this likely to be fixed?
bill
Is this likely to be fixed?
bill
Jan-Erik Söderholm
Oct 15, 2023, 3:57:26 PM10/15/23
to
Den 2023-10-15 kl. 21:18, skrev William Cox:
> So it's been seven years since this was posted. I just tried the sample programs on x86_64 V9.2-1 and it still looks like the same problem exists. I can see the semaphore file in the PSX$SEMAPHORES directory, but the open fails.
>
>
>
> bill
> So it's been seven years since this was posted. I just tried the sample programs on x86_64 V9.2-1 and it still looks like the same problem exists. I can see the semaphore file in the PSX$SEMAPHORES directory, but the open fails.
>
>
>
> I just tried the sample programs
> Is this likely to be fixed?
What does "this" refer to?
Stephen Hoffman
Oct 15, 2023, 5:50:12 PM10/15/23
to
On 2023-10-15 19:57:22 +0000, Jan-Erik Söderholm said:
> Den 2023-10-15 kl. 21:18, skrev William Cox:
>> So it's been seven years since this was posted. I just tried the sample
>> programs on x86_64 V9.2-1 and it still looks like the same problem
>> exists. I can see the semaphore file in the PSX$SEMAPHORES directory,
>> but the open fails.
>>
> Den 2023-10-15 kl. 21:18, skrev William Cox:
>> So it's been seven years since this was posted. I just tried the sample
>> programs on x86_64 V9.2-1 and it still looks like the same problem
>> exists. I can see the semaphore file in the PSX$SEMAPHORES directory,
>> but the open fails.
>>
>> Is this likely to be fixed?
An entity with support can certainly log a bug report with VSI.
This case certainly seems to have escaped the testing.
Wrapping the POSIX semaphore calls—as a workaround, pending a fix from
VSI—would be less than fun.
Sorting out the installation-versus-upgrade differences in an OpenVMS
environment that was also mentioned up-thread is also less than fun.
There's also no contents-migration support within OpenVMS that might be
used to "repair" these cases with missing or mis-constructed
directories, too.
> What does "this" refer to?
Jake Hamby (Solid State Jake)
Oct 16, 2023, 12:48:21 AM10/16/23
to
On Sunday, October 15, 2023 at 2:50:12 PM UTC-7, Stephen Hoffman wrote:
> On 2023-10-15 19:57:22 +0000, Jan-Erik Söderholm said:
>
> > Den 2023-10-15 kl. 21:18, skrev William Cox:
> >> So it's been seven years since this was posted. I just tried the sample
> >> programs on x86_64 V9.2-1 and it still looks like the same problem
> >> exists. I can see the semaphore file in the PSX$SEMAPHORES directory,
> >> but the open fails.
> >>
> >> Is this likely to be fixed?
> An entity with support can certainly log a bug report with VSI.
>
> This case certainly seems to have escaped the testing.
>
> Wrapping the POSIX semaphore calls—as a workaround, pending a fix from
> VSI—would be less than fun.
>
> Sorting out the installation-versus-upgrade differences in an OpenVMS
> environment that was also mentioned up-thread is also less than fun.
>
> There's also no contents-migration support within OpenVMS that might be
> used to "repair" these cases with missing or mis-constructed
> directories, too.
FWIW, the equivalent System V semaphores appear to work on my V9.2-1 system, based on a rewrite of the POSIX semaphore test cases (which don't work for me either).
> On 2023-10-15 19:57:22 +0000, Jan-Erik Söderholm said:
>
> > Den 2023-10-15 kl. 21:18, skrev William Cox:
> >> So it's been seven years since this was posted. I just tried the sample
> >> programs on x86_64 V9.2-1 and it still looks like the same problem
> >> exists. I can see the semaphore file in the PSX$SEMAPHORES directory,
> >> but the open fails.
> >>
> >> Is this likely to be fixed?
> An entity with support can certainly log a bug report with VSI.
>
> This case certainly seems to have escaped the testing.
>
> Wrapping the POSIX semaphore calls—as a workaround, pending a fix from
> VSI—would be less than fun.
>
> Sorting out the installation-versus-upgrade differences in an OpenVMS
> environment that was also mentioned up-thread is also less than fun.
>
> There's also no contents-migration support within OpenVMS that might be
> used to "repair" these cases with missing or mis-constructed
> directories, too.
I say they "appear" to work because I was never able to figure out why a test IPC benchmark that I ported to VMS a few years ago either hangs or fails randomly with an error in the child shmget, the parent shmat, or both. Link to the source file, shm.c:
https://github.com/jhamby/vms-ipc_benchmark/blob/jhamby/vms-port/shm.c
All of the benchmarks have the same basic format: the first argument is the size of the message and the second is the number of messages to send. The parent forks a child and the messages are sent in one direction. I've modified them all to work with VMS by exec'ing the program itself with a special command-line flag to signal that it should run as a child. So I know that modification works in the other variants of the test.
shm.c creates a SYSV shared memory segment of the requested size, then uses a set of two SYSV semaphores to coordinate when to write and when to read. On Linux, this is noticeably slower than pipes, TCP sockets, or any other method, and I expect it to also be slow on VMS. What I didn't expect is for it to fail and/or hang every time.
The current version of the code gives a duplicate symbol warning because it has its own local definition of sem_init(), so I'll have to rename that function, but it's not the cause of the bug. I also discovered that putting a printf() statement or a usleep(5) inside the read and write loops causes the program to work, as does keeping the iteration count under 20 (but then I get "InfinityMB/s Infinitymsg/s").
It must be some sort of race condition having to do with acquiring and releasing two SYSV semaphores within a set from two threads in rapid succession. Itanium fails the same way as x86-64.
Regards,
Jake Hamby
Vitaly Pustovetov
Oct 16, 2023, 12:56:32 AM10/16/23
to
Oops, I should have fixed it earlier. The current version of semaphores is full of errors and it was probably right for me to rewrite everything to use the DLM instead of the current idiocy with files.
William Cox
Oct 16, 2023, 10:04:29 AM10/16/23
to
> What does "this" refer to?
The last 2016 post from John Reagan had "I'll add it to the list...". I suspect the list just keeps getting longer.
bill
Vitaly Pustovetov
Oct 16, 2023, 10:57:39 AM10/16/23
to
I've fixed the bug. After the patch:
$ r sem_bug
[OK] Semaphore created
$ r sem_bug2
[OK] Semaphore opened
$ r sem_bug3
[OK] Semaphore unlinked
p.s. Yes, we have a long list of errors. ;)
$ r sem_bug
[OK] Semaphore created
$ r sem_bug2
[OK] Semaphore opened
$ r sem_bug3
[OK] Semaphore unlinked
p.s. Yes, we have a long list of errors. ;)
Message has been deleted
William Cox
Oct 16, 2023, 1:03:50 PM10/16/23
to
Vitaly Pustovetov
Oct 17, 2023, 11:57:16 AM10/17/23
to
понедельник, 16 октября 2023 г. в 19:03:50 UTC+2, William Cox:
> Thank you. I assume this will show up in some future update.
Yes, it will be in a future update. I hope in the next update.
> Thank you. I assume this will show up in some future update.
0 new messages