DIR Return Create A Forum - Home
       ---------------------------------------------------------
       Class H22
  HTML https://classh22.createaforum.com
       ---------------------------------------------------------
       *****************************************************
   DIR Return to: Summeries
       *****************************************************
       #Post#: 59--------------------------------------------------
       IPC
   DIR By: SpiderGoat
       Date: April 9, 2014, 9:09 am
       ---------------------------------------------------------
       inter process communication
       separating job to few processes has its problems.
       dividing job between few CPUs make things faster.
       do you need to see intermediate pruduct?
       do you need to proceed in a row or in parallel?
       
       info is to be delivered between processes.
       minimum of data length is byte.
       it should be pass as a signal.
       the pipeline is a buffer of bytes. a queue.
       the buffer handle the difference in tempo of I/Os.
       ls *.c | grep xyz
       two commands that work together, using pipeline.
       mesage queue - a whole package of data.
       while delivering data between processes, it should pass via OS,
       unless both using a SAME SHARED MEMORY.
       spin lock, semaphores and Mutex make sure no one disturb the
       other.
       i++ or ++i - race condition. which function beats the line. r/w
       acess to same resource.
       critical sections - where in program a shred memory is called.
       should be short.
       the two programs will enter critical regions in separated
       times.
       while, each hold the "only key".
       mutex - mutual exclusion
       conditions:
       only one in critical section
       no assumption on speed
       process will block other only if inside.
       no starvation.
       disable interrupt
       not reccomanded.
       used in OS with interrupt drivers, and only for short clocks.
       lock variable
       problem - race condition on flag.
       spin lock
       each process is busy waiting until own turn - wastes CPU time.
       not for user level code.
       locks all but one - like a chairs-game. or the one who holds
       the pen talks.
       but, the lock itself is a shared resource.
       TSL
       read the content of lock and write in one single machine
       instruction.
       locks the bus until command is finished. no race to source.
       causes busy-waiting.
       Peterson
       makes the 2 processes lokk in different directions.
       two variables that do flip-flop.
       producer-consumer problem
       n places for items, one insert items, and one consumes.
       consumption if exists.
       insertion if there is place to.
       shared data, and interrupt may dissynchronise.
       
       semaphore - counter for resources.
       while updating semaphore, process sleeps.
       can't be negative. while asing resource, counter drops to 0 and
       process sleeps until enough flags raised.
       binary (1/0) or general(counting).
       binary is for mutex-like. general for is synchronization.
       
       priority inversion
       mid priority is running.
       high priority waiting for semaphore,
       while low holds the semaphore and can't leave because mid
       starve all.
       this is priority inversion.
       low should have higher priority, so it can leave, and let real
       high priority act.
       solution
       higher priority of holder for a moment.
       
       *****************************************************
       Page 1 of 1