<div dir="ltr">Hi all,<div><br></div><div>This week I have implemented sysv semaphores in userland. The hole idea is based on the shared memory implementation. A call to <i>semget</i> is a <i>shmget</i> and a <i>shmat.</i> The client stores information about each sysv resources in a structure (file descriptor, the size of the file, the type of sysv resource). In semaphores case, the client stores the address where there are mapped in memory.</div>
<div><br></div><div><i>shmctl</i> is implemented as messages sent to the daemon or as simple reads from memory. IPC_RMID, IPC_STAT and IPC_SET call <i>smhctl</i> that sends a message to the daemon. IPC_STAT is used to find out data about the sysv resource. In semaphores case, there are some extra fields (that are not available for shared memory). Those are read from the memory (same area the semaphore is mapped). For all other commands, data are read/written from/in the shared memory area.</div>
<div><br></div><div><i>semop</i> is similar with the kernel implementation. For SEM_UNDO flag (used to store changes made by a process in order to be undone when it finishes its execution) I used a shared memory segment too. When this area is created, the daemon mark it so that it can use it when the process dies. Its initial size is PAGE_SIZE but it growths each time is no more space to be written.</div>
<div><br></div><div>The client uses some structures (hashtables, locks) to store information about the sysv resources. All can be safely used in multithreading applications.</div><div><br></div><div>Larisa</div></div>