[GSOC] System V IPC in userspace week6 report

[grigore larisa <larisagrigore@xxxxxxxxx>]

--089e011836781cce4d04e2997601
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

This week I have implemented sysv semaphores in userland. The hole idea is
based on the shared memory implementation. A call to *semget* is a *shmget* and
a *shmat.* 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.

*shmctl* is implemented as messages sent to the daemon or as simple reads
from memory. IPC_RMID, IPC_STAT and IPC_SET call *smhctl* 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.

*semop* 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.

The client uses some structures (hashtables, locks) to store information
about the sysv resources. All can be safely used in multithreading
applications.

Larisa

--089e011836781cce4d04e2997601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<div><br></div><div>This week I have implemented sy=
sv semaphores in userland. The hole idea is based on the shared memory impl=
ementation. A call to <i>semget</i>=A0is a <i>shmget</i>=A0and a <i>shmat.<=
/i>=A0The client stores information about each sysv resources in a structur=
e (file descriptor, the size of the file, the type of sysv resource). In se=
maphores case, the client stores the address where there are mapped in memo=
ry.</div>
<div><br></div><div><i>shmctl</i>=A0is implemented as messages sent to the =
daemon or as simple reads from memory. IPC_RMID, IPC_STAT and IPC_SET call =
<i>smhctl</i>=A0that sends a message to the daemon. IPC_STAT is used to fin=
d out data about the sysv resource. In semaphores case, there are some extr=
a fields (that are not available for shared memory). Those are read from th=
e 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>=A0is similar with the kernel implementatio=
n. For SEM_UNDO flag (used to store changes made by a process in order to b=
e 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 multi=
threading applications.</div><div><br></div><div>Larisa</div></div>

--089e011836781cce4d04e2997601--