Req #44109 [Opn->Wfx]: sem_remove does not seem to take SYSVSEM_USAGE into account

From: Date: Tue, 09 Nov 2021 10:11:49 +0000
Subject: Req #44109 [Opn->Wfx]: sem_remove does not seem to take SYSVSEM_USAGE into account
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-237643@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=44109&edit=1 ID: 44109 Updated by: cmb@php.net Reported by: thornza at yahoo dot com Summary: sem_remove does not seem to take SYSVSEM_USAGE into account -Status: Open +Status: Wont fix Type: Feature/Change Request Package: Semaphore related Operating System: Linux PHP Version: 5.2.5 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: > processA sem_remove()s the semaphore ***THE SEMAPHORE HAS NOW BEEN REMOVED - > I think that this part is incorrect**** This is how System V semaphores are supposed to work, and that cannot be changed in PHP, but rather has to be left to userland. You need to ensure that the process that creates the semaphore, removes it when it is no longer needed. Practically, that is done by a server process. Previous Comments: ------------------------------------------------------------------------ [2012-08-23 06:56:13] norman dot geist at uni-greifswald dot de I just got the same annoying problem as the poster. I tried to use the semaphores with shared memory to create an openmp like parallelism to php scripts and apps. The problem now is, that if I parallelize a for loop with dynamic scheduling (next free cpu takes next iteration to do) will cause sem_get to run out of semaphore identifiers for the same semaphore. This maximum number of about 32000 seem not to be adjustable. But I can also not use sem_remove to really free the sem ids because the other processes can't access the semaphore no more. Like this, the semaphores seems just unusable (against their original intention). ------------------------------------------------------------------------ [2008-02-13 13:26:54] thornza at yahoo dot com Description: ------------ Two processes - processA and processB - are using a semaphore. processA sem_get()s the semaphore. (the semaphore is created) processB sem_get()s the semaphore. (the semaphore is already created, so the semaphore id is just returned) processA sem_acquire()s the semaphore and begins to work in the critical section. processB sem_acquire()s the semaphore and BLOCKS. processA finishes in it's critical section and sem_release()s. processA sem_remove()s the semaphore ***THE SEMAPHORE HAS NOW BEEN REMOVED - I think that this part is incorrect**** processB now is NOT able to continue as the semaphore has been removed. sem_remove() should take the SYSVSEM_USAGE (see sysvsem.c) count into consideration when it is called. Only if this count is == 1 should the semaphore be removed. This will allow the last process that is using the semaphore to remove it from the system. Reproduce code: --------------- <?php //Note - run this script from two different clients at the same time. //add your own critical section code and output logging. $semKey = 1234; $semHandle = sem_get($semKey, 1, 0666, FALSE); sem_acquire($semHandle); //critical section //do something useful here sem_release($semHandle); sem_remove($semHandle); ?> Expected result: ---------------- processA and processB both able to work in their critical sections without error. Actual result: -------------- Log messages such as the following are generated: [13-Feb-2008 14:36:30] PHP Warning: sem_acquire() [<a href='function.sem-acquire'>function.sem-acquire</a>]: failed to acquire key 0x2b72: Invalid argument in /opt/MarkDW/Exec/Form.php on line 1282 ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=44109&edit=1

« previous php.bugs (#237643) next »