Bug #16986 [Com]: semaphore autorelease can be a bug....

Edit report at https://bugs.php.net/bug.php?id=16986&edit=1 ID: 16986 Comment by: alhira500 at gmail dot com Reported by: AlberT at SuperAlberT dot it Summary: semaphore autorelease can be a bug.... Status: Closed Type: Bug Package: Semaphore related Operating System: Linux 2.4.18 PHP Version: 4.1.2 Block user comment: N Private report: N New Comment: It may be difficult, but in your own handwriting ... if you try to write. And if you get stuck, adjust and go with the forgotten rope. I think an automatic transmission can be a good standard, but changing this behavior is very important. If you want to solve the classic IPC problem (see Tanenboom!) You have to stay in the season and not sell anymore. Here's an explanation of the problem you are facing Automatic release can not be selected: https://krnl.ltd/ Previous Comments: ------------------------------------------------------------------------ [2022-01-10 11:17:18] abdullahmalad at gmail dot com Thanks for the info, try to understand more. http://beetvapp.me/ ------------------------------------------------------------------------ [2022-01-10 11:13:39] rahulkunal250 at gmail dot com After query processing, all traffic lights obtained from the process however not explicitly deleted, automatically deleted and warned was created. It doesn't matter, in fact the readers / writers are like that The classic IPC problem is that writers cannot set priorities do !!! I think the option to turn off automatic output is useful. https://krnl.onl/ ------------------------------------------------------------------------ [2021-02-12 10:31:23] ednahicks198931 at gmail dot com Thanks for the info i will try to figure it out for more. https://www.upsers.online/ ------------------------------------------------------------------------ [2002-05-17 08:37:00] wez@php.net The new proto for sem_get is: proto int sem_get(int key [, int max_acquire [, int perm [, int auto_release]]) auto_release defaults to true so original behaviour is preserved; you may specify false to override. ------------------------------------------------------------------------ [2002-05-07 10:58:07] AlberT at SuperAlberT dot it Some people write me for explanations..... ok I'll be more clear I hope: READER: p(mutex); readcount++; if (readcount is 1) then p(db); v(mutex); CRITICAL REGION where we read p(mutex); readcount--; if (readcount is 0) then v(db); v(mutex); WRITER: p(db); CRITICAL REGION where we write v(db); this is the simplest r/w problem, ok ?!? let we analize it now. we have to acquire some mutex to protect owr access to variables readcount ok ?? This is possible in PHP! .. ok ! now, I'm the 1st reader .. I acquire sem DB becouse readcount is equal to 1, I release mutex and begin to READ NOW IT IS possible that an other reader arrive and it is faster than me; it DON'T acquire DB becouse readcont is now 2, it READS and DOESN'T HAVE to release sem DB becouse readcount IS NOT 1 (reader 1 is still reading !!)... PHP AUTORELEASE DB ... damn !!! ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=16986 -- Edit this bug report at https://bugs.php.net/bug.php?id=16986&edit=1