Stackoverflow offers a nice little comparison between XSI and Posix smaphores here:
https://stackoverflow.com/questions/11058045/differences-between-semaphore-h-and-sys-sem-h Stevens & Rago, in "Advanced Programming in the Unix Environment", section 15.8: http://www.apuebook.com/toc3e.html provide these comments: 1. A semaphore is not simply a single non-negative value. Instead, we have to define a semaphore as a set of one or more semaphore values. When we create the semaphore, we specify the number of values in the set. 2. The creation of a semaphore (semget) is independent of its initialization (semctl). This is a fatal flaw, since we cannot atomically creste a new semaphore set and initialize all the values in the set. 3. Since all forms of XSI IPC remain in existence even when no process is using them, we have to worry about a program that terminates without releasing the semaphores it has allocated. The undo feature that we describe later is supposed to handle this. Unix System Services Planning, in the section "Managing Interprocess Communication (IPC)": https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxb200/ipcm.htm notes that: Users can invoke applications that create IPC resources and wait for IPC resources. IPC resources are not automatically released when a process is ended or a user logs off. Therefore, it is possible that an IPC user might need assistance to do either of the following: * Remove an IPC resource using the shell's ipcrm command * Remove an IPC resource using the shell's ipcrm command to release a user from an IPC wait state This last reference just hints at another problem: semaphores are a limited resource, and if they are not properly cleaned up, they can be exhausted. The "Troubleshooting" page for IBM's implementation of node.js refers to this: https://www.ibm.com/support/knowledgecenter/en/SSTRRS_6.0.0/com.ibm.nodejs.zos.v6.doc/troubleshoot.htm Node.js uses z/OS UNIX System Services semaphores. If the Node.js runtime ends unexpectedly, stale semaphores might be left on the system, potentially resulting in a lack of available semaphores for invoking more Node.js instances. Currently, you must manually clean up stale semaphores, by using the ipcrm command. Too many stale semaphores results in the following node assert or error: CEE3204S The system detected a protection exception (System Completion Code=0C4). From entry point _ZN4node6AssertEPA4_KPKc at compile unit offset +0000000025F3AC86 at entry offset +00000000000000BE at address 0000000025F3AC86. I'll add this description of the "limitations" of XSI semaphores to the RFE. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
