viernes, 9 de septiembre de 2011

Primera presentación teórica


LOCKS (code)
Lock::Lock(const char* debugName) {
  name = debugName;
  s = new Semaphore(name,1);
  locked = true;
  owner = NULL;
}

Lock::~Lock() {
  delete s;
  delete owner;
}

void Lock::Acquire() {
  s->P();
  locked = true;
  owner = currentThread;
}

bool Lock::isHeldByCurrentThread() {
  return(owner == currentThread);
}

void Lock::Release() {
  if(locked && isHeldByCurrentThread()) {
    locked = false;
    owner = NULL;
    s->V();
  }
}
CONDITIONAL VARIABLES (code)
Condition::Condition(const char* debugName, Lock* conditionLock) {
  name = debugName;
  l = conditionLock;
  queue = new List;
}

Condition::~Condition() {
  delete l;
  delete queue;
}

void Condition::Wait() {
  Semaphore *temp;
  
  if(l->isHeldByCurrentThread()) {
    temp = new Semaphore("condition", 0);
    queue->Append(temp);
    l->Release();
    temp->P();
    l->Acquire();
    delete temp;
  }
}

void Condition::Signal() {
  Semaphore *temp;
  
  if(l->isHeldByCurrentThread()) {
    if(!queue->IsEmpty()) {
      temp = queue->Remove();
      temp->V();
    }
  }
}

void Condition::Broadcast() {
  while(!queue->IsEmpty()) {
    Signal();
  }
}

10 comentarios:

  1. in the consumer function .. if you acquire the lock before check if you can 'eat' ... you are wasting some CPU, or i am wrong?

    if you can't eat, then don't bother.

    ResponderEliminar
  2. bueno no estoy muy segura Ever pero lo que entendi es que cuando usas yield.. se cede el paso al otro proceso entonces el productor puede "producir" entonces ya una vez que produjo y solto el candado el consumidor entra en donde se habia quedado despues del yield,, es poreso que ocupas un candado para entrar en su seccion critica, asi es como lo analizo...que piensas tu?

    ResponderEliminar
  3. Bueno, lo que pasa es qe al momento de iniciar el consumer, si tu checas si tiene algo para 'consumir' y despues tomas el candado y haces el consumo, eso podria optimizar un poco el uso del cpu, no?
    de otra manera el consumidor iniciaria tomaria el candado y si no hay nada para consumir eso quiere decir que fue una perdida de CPU darle el candado.

    si no puedes consumir, entonces para que molestas :P

    ResponderEliminar
  4. pero si tu (eres un thread) checas si puedes consumir y justo en el instante que quieres tomar el lock eres interrumpido por el scheduler y un rato despues regresas donde te quedaste (tomar el candado), pero por alguna razon ya no puedes consumir por que alguien mas se acabo todo lo que habia disponible, pero tu no te das cuenta por que segun tu podias comer y tomas el lock entonces tratas de consumir algo que no existe, en cambio si tomas el lock antes de checar aseguras que mientras tu checas nadie mas puede modificar el valor el cual tu (siendo un thread) quieres modificar

    ResponderEliminar
  5. sería bueno que tuvieran dos locks, porque cuando un consumidor se da cuenta que no puede comer libera el lock, con la intencion de que algún productor lo tome y ponga algo, pero si lo vuelve a tomar un consumidor va a volver a checar y se dara cuenta de que no puede comer y liberara el lock, en el peor caso en varias ocasiones tocaran consumidores que no puedan consumir lo que da lugar a perdida de recursos.

    ResponderEliminar
  6. Es necesario bloquear el acceso al recurso que es modificado por varios hilos, si el consumidor entra en accion y solamente verifica sin tomar el candado entonces no hay nada que le garantice que el recurso no ha sido alterado; sin embargo, si bloqueas el acceso al recurso puedes verificar sin peligro a que el recurso sea alterado y salir de la comprobación con la seguridad que estuvo bien lo que hiciste.
    Como dice Jorge, tambien existe la posibilidad que cuando el consumidor entre en ejecucion nuevamente no exista ya el recurso que estas intentando accesar puesto a que no bloqueaste el acceso y alguien mas te lo gano, intentaras consumir algo que no existe.
    Jorge: No entiendo tu concepto de dos candados, no creo que sea necesario ya que si implementas 2 o mas consumidores, cuando todos se den cuenta que no pueden consumir simplemente dejan el candado y entran en Yield(), con ello ya no hay consumo de recursos y el productor felizmente continua agregando recursos. En este caso y en otros mas necesitas un candado por recurso modificado, un segundo candado... ¿Para qué? Ojalá puedas ampliar tu argumento.

    ResponderEliminar
  7. Entiendo tu punto en la parte del Yield(), pero recuerda que tu pones el Yield() en tu codigo con el fin de dar chance a los demas threads de ejecutar su codigo, y cuando pasa eso podemos decir que se ponen al final de la cola para volver a ejecutarse hasta que al menos todos hicieron un Yield() y para el caso de un scheduler FCFS el algoritmo funciona perfectamente.
    Pero la idea de dos locks es propuesta para un caso mas general donde tu no tienes que poner Yield(), sino que el scheduler interrumpe la ejecucion de un thread a propio gusto, por lo cual ahi tendrias la posibilidad de que el scheduler te de la siguiente secuencia:
    nadie puede comer se paran los consumidores, manda llamar un productor, manda llamar un consumidor y manda a llamar los demas consumidores los cuales no pueden consumir y se paran y asi sucesivamente en algunos intervalos de tiempo lo cual gasta algunos recursos.

    ResponderEliminar
  8. ademas imagina que tienes muchos consumidores, entonces si no uno no puede consumir bloquea a los demas y estos ya no gastan tiempo en checar si les es permito consumir y se bloquan hasta que tienen la posibilidad de consumir lo cual es un ahorro de tiempo si pensamos que esto va a suceder varias veces mientras corramos el programa, ademas lo pienso para una maquina con un procesador no muy rapido digamos algo embebido como un micro donde se pueden realizar menos operaciones por segundo y con lo anterior hacemos mas rapido el codigo a cambio de un poco mas de memoria la cual no seria demasiada (creo).

    ResponderEliminar
  9. +1 presentado parcialmente en inglés
    +2 PC
    +1 discussion of quality
    +2 DF
    +1 locks
    +1 CV
    +1 diapositivas en inglés
    => 9 puntos
    Puntos extra individuales para: Everardo, Cecy, Jorge y Juan Carlos

    ResponderEliminar