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

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

> I just tried the sample programs
> Is this likely to be fixed?

What does "this" refer 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.
>>
>> 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?

This → https://groups.google.com/g/comp.os.vms/c/ySlKal2n51Y/m/WgKks-1KAwAJ

--
Pure Personal Opinion | HoffmanLabs LLC

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).

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

> 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

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. ;)

On Monday, October 16, 2023 at 10:57:39 AM UTC-4, Vitaly Pustovetov wrote:
> 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. ;)

On Monday, October 16, 2023 at 10:57:39 AM UTC-4, Vitaly Pustovetov wrote:
> 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. ;)

Thank you. I assume this will show up in some future update.