php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #44109 sem_remove does not seem to take SYSVSEM_USAGE into account
Submitted: 2008-02-13 13:26 UTC Modified: 2021-11-09 10:11 UTC
Votes:17
Avg. Score:4.8 ± 0.5
Reproduced:14 of 14 (100.0%)
Same Version:2 (14.3%)
Same OS:12 (85.7%)
From: thornza at yahoo dot com Assigned: cmb (profile)
Status: Wont fix Package: Semaphore related
PHP Version: 5.2.5 OS: Linux
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2008-02-13 13:26 UTC] 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

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-02-21 20:50 UTC] jani@php.net
-Package: Feature/Change Request +Package: Semaphore related
 [2012-08-23 06:56 UTC] 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).
 [2021-11-09 10:11 UTC] cmb@php.net
-Status: Open +Status: Wont fix -Assigned To: +Assigned To: cmb
 [2021-11-09 10:11 UTC] cmb@php.net
> 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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 09:01:30 2024 UTC