Re: duvidas, alguem ajuda?

[Alex Pires de Camargo <acamargo@linux.ime.usp.br>]

Fabio Silva Dias writes:
> > Bom to com uma duvida tambem...
> > Não tava naquela aula que ele falou dos locks na hash, alguem podia me
> > explicar...
> 
> Normalmente a função de hash ao receber a chave e fazer a conversão para um
> elemento de um vetor na verdade faz a conversão para uma referência a uma
> lista ligada, contendo todos os elementos da tabela de hash cuja chave está
> relacionada com o índice do vetor.
> Acho que fui meio confuso é melhor dar um exemplo. Suponha que temos uma
> tabela de hash com os elementos "joao", "pedro", "paulo", "jonas",
> "ze_jacare" e "plebeu".
> E que no nosso caso, na estrutura interna do hash os elementos são
> índice 0 do vetor - lista contendo [joao, jonas]
> índice 1 do vetor - lista contendo [pedro, paulo, plebeu]
> índice 2 do vetor - lista contendo [ze_jacare]
> Se eu quiser acessar o elemento cuja chave é "paulo" eu vou ter que na
> verdade acessar o índice 1 do vetor e depois percorrer a lista referenciada
> por este índice até chegar em "paulo".
> Qual é a melhor alternativa de controle de concorrência para esta tabela?
> Você pode fazer três tipos de lock:
> - ou "locka" a o vetor todo durante uma busca por um elemento na tabela de
> hash. é evidente que este tipo de lock é meio ruim, pois perde-se muita
> concorrência.
> - ou "locka" somente o elemento que você quer consultar (no caso "paulo").
> So que para isso, eu antes precisaria fazer um lock em "pedro" e se alguem
> quiser acessar "plebeu" vai precisar esperar eu liberar o lock de "paulo" e
> depois o de "pedro". Isto não é muito legal, porque se tivessemos uma lista
> com 500 elementos, para acessar o elemento de n.o 500 eu precisaria fazer
> 500 locks e fazer um lock é algo caro, queremos minimizar o número de locks.
> - ou "locka" o índice do vetor que contém o elemento a ser procurado. Neste
> caso eu faria apenas um lock no índice 1 e poderia acessar livremente a
> lista [pedro, paulo, plebeu]. Se alguem quiser acessar "plebeu" ou "pedro"
> vai ter que esperar eu liberar o lock da lista.
> A terceira opção é a melhor de se usar porque minimiza o número de locks e
> também nos garante boa concorrência, pois podemos ter um vetor muito maior
> do que o do meu exemplo se tivermos muitos dados a acessar.

	QUal a diferença entre a solucao dois e três?


> > Valeu
> > Dea
> 
> Agora eu é que tenho uma dúvida: o que é o tal do "nested monitors
> lockout"??? Como evitá-lo?

Monitor Foo{

op1(){
  wait();
}

op2(){
  notify();
}

}

Monitor Foo2{
  Foo f=...

op1(){
  f.op1();
}

op2(){
  f.op2();	
}
}


void main{
  Foo2 detona=...

  detona.op1();
  detona.op2();
}

	O main vai parar no chamada de op1, pois apesar do Objeto Foo
entrar em wait e soltar a trava para alguem rodar Foo.op2, o lock do
obejto Foo2 não foi solto, e ninguém vai conseguir chamar Foo2.op2().
	Daí vem aquele papo do Doug Lea de não colocar synhcronized em
métodos que chamam métodos synchronized.
	Se eu estiver viajando favor me avisem, de preferência antes
da prova :).

						[]s

> 
> 
*************************************************************************
* Alex Pires de Camargo                 *      Debian GNU/Linux         *
* e-mail:acamargo@linux.ime.usp.br      * The biggest is still the best *
* http://www.linux.ime.usp.br/~acamargo *    http://www.debian.org      *
*************************************************************************