Shared memory design considerations

-different APIs/mechanisms for synchronization
-os provides shared memory, and is out of the way
-data passing/sync protocols are up to the programmer

large segment => manager for allocating/freeing mem from shared segment
many small segments => use pool of segments, queue of segment ids
=> communicate segment IOs among processes

synchronization is like … waiting for a coworker to finish so you can continue working
-may repeatedly check to continue
-may wait for a signal to continue
-waiting hurts performance

mutexes
condition variables
why more?
error prone/correctness/ease-of-use
lack of expressive power

Low level support
-hardware atomic instructions

Spinlocks(basic sync construct)
spinlock is like a mutex
-mutual exlusion
-lock and unlock(free)

spinlock_lock(s);
	// critical section
spinlock_unlock(s);

semaphores
-common sync construct in OS kernels
-like a traffic light: STOP and GO
-similar to a mutex… but more general

on init
-assigned a max value(positive int)
on try(wait)
– if non-zero => decrement and proceed
if initialized with
– semaphore == mutex (binary semaphore)
on exit(post)
– increment

#include <semaphore.h>

sem_t sem;
sem_init(sem_t *sem, int pshared, int count);
sem_wait(sem_t *sem);
sem_post(sem_t *sem);