Resumo Modelos de Escalonamento

Resumo:

- O modelo de escalonamento de threads em java não é definido por uma especificação, isso significa que o comportamento varia de plataforma(Nativa) para plataforma(Nativa) e claro a implementação da JVM.

- Java é uma plataforma independente, oque implica a não necessitar saber sobre detalhes de implementação da Plataforma Nativa POREM em alguns casos os detalhes importam!

- A maioria dos computadores tem apenas uma CPU disponível oque, acarreta em escalonamento de threads mediante ao core.

- O modelo de Prioridade, é realmente o único ao qual pode-se fazer Afirmação, Na implementação das Jvms, threads com maior prioridade terão preferência para se Tornarem Running do que thread de menor prioridade.

- threads de Mesma prioridade seguem em cada S.O. E cada implementação de JVM uma idéia diferente(um modelo Diferente), cabe ao programador fazer as manipulações certas.

- O S.O Realmente importa – Em alguns casos de acordo com o Sistema de escalonamento do S.O. sera como o seu programa multiThread se comportara, então fica melhor você garantir que seu programa funcionara de acordo, usando yield(), sleep() ,wait() noticy etc... Isso para programas com mais de uma Thread Cpu Intensive

- Thread scheduling

Em programas multiThread, as threads dividem as CPUS. OU a JVM, ou o S.O. decide como dividir os CPUS e isso é conhecido como Thread scheduling. Seja a Jvm ou o S.O. é conhecido como Thread scheduling quem faz a divisão das CPUS(ou da CPU) ,o programador entra com “manipulações” dessas divisões das CPUs.

- Temos 3 tipos básicos de programas em nível de caracterização:

CPU intensive: Vários ciclos

I/O intensive: Aguarda I/O

Interactive: Evento

- O escalonador de java é baseado na prioridade das threads. Isso significa que as threads são assinadas com uma certa prioridade, um valor inteiro positivo. APENAS O PROGRAMADOR pode trocar a prioridade. Ou seja se uma thread nasce com uma prioridade, mesmo que ela passe por todos os estados possíveis, ela morrerá com a mesma prioridade. - (Ou seja, 2 threads, A prioridade 5, B prioridade 6, A esta Running, B entra em Runnabl(b.start())...A e B vão para o Pool de threads Runnable, e a thread que será dada a CPU é para B, pois tem maior prioridade)-

- Temos 2 tipos de modelos de implementação de threads:

*The green-thread model - as threads são gerenciadas somente pela JVM.É o modelo mais comum.

*The native-thread model - as threads são gerenciadas pelo S.O. que é hosta da JVM(O escalonador do S.O.)

- QUANDO DEVO TOMAR CUIDADO?

- Quando tenho mais de um CPU-Intensive no programa

- Quando resultados parciais são importantes, ainda mais se eles forem compartilhados

- Quando threads não estão fazendo tarefas associadas; as threads estão fornecendo tarefas separadas que vão se integrando, ou empregando um paradigma de round-robin scheduling(Um programa de servidor que responde a requisições de diferentes usuários) ou empregando um paradigma de Escalonador(um servidor que processa requisições de usuários )

- QUANDO ACONTECE A MUDANÇA DE UMA THREAD PARA OUTRA?

NESSES CASOS:

* Uma thread de prioridade maior entre na historia

* yield() seja invocado, stop(), ou run() termine o code_blocK

* Ou em um sistema que suporte time-slicing diga que o tempo de uso terminou.

- Quando configurar a prioridade de threads é importante?

- Quando temos apenas uma CPU intensive thread(ou uma CPU somente na máquina)

- resultados intermediários são importantes

- Oque são resultados intermediários?

Ex: Temos uma thread CPU intensive(que tem um loop, que faz contas e a cada loop ele mostra para o user o resultado) e temos um thread Interactive(que fica esperando uma ação do usuário, claro temos que fazer os 2 ao mesmo tempo), então a thread que é CPU intensive ao fazer uma conta, mostra para o user o resultado(so que ela faz essa conta "n" vezes), porem cada resultado é importante, não somente o resultado final... na 1x que faz a conta sai o resultado para o user, na 2x que faz a conta sai o resultado para o user, na 3x que faz a conta sai o resultado para o user e assim por vez... Isso enquando a thread de INTERACTIVE não recebeu nenhum evento...isso que é chamado de resultado intermediario.

- Round-robin é um algoritmo de escalonamento usado em computadores no qual um número determinado de processos ocorrem com um intervalo de tempo também determinado. - Ele usa aquele conceito de lista, oque estiver em cima é executado e vai para o fundo.(ELE É implementando em alguns S.O.) Dele deriva também o termo de Time-Slicing(Falando em quesitos de thread e implementação da JVM de recursos do S.O.).

- Time-slicing é um termo que vem de múltiplas threads no estado "Runnable" de mesma prioridade que são as de mais alta prioridade no sistema e estão competindo pela CPU(ou seja um pc só com uma CPU, e elas querem se tornar RUNNING).

- Quando uma thread é criada, a thread herda a prioridade da thread que a criou. Você pode modificar a prioridade de uma thread a qualquer momento usando o setPriority().

- USER LEVEL THREADS X SYSTEM LEVEL THREADS:

Em grande parte dos S.O., o S.O é dividido em duas partes: User level e System level. O KERNEL do S.O. é quem responde as System level threads e também é quem representa o S.O. em chamadas de programas que rodam em User level.

Quando um programa do user quer ler um arquivo, por exemplo, o programa tem que fazer uma chamada ao kernel do S.O. o qual, lera os dados e retornara ao programa. Porque disso?

SE um programa fizer uma operação ilegal de sistema, antes disso ocorrer passa pelo kernel do S.O. oque ja sabe oque esta ocorrendo e termina o programa antes que afete outros programas ou o próprio S.O.

Por causa dessa separação é possível ter user leve threads, system level threads ou ambos independentemente.

- O GREEN MODEL:

* Normalmente são chamadas de user - level thread

* Não usa habilidades particulares a um S.O.

* Não suportam threads Nativas

* Esta na maior parte de S.O. derivado de UNIX(Embora grande parte do S.O tambem suportem native-thread model)

* As threads não são conhecidas pelo S.O - Somente a JVM sabe e gerencia

* So podemos executar uma thread por vez na CPU -Consequentemente não pegam as vantagens de multi processadores(Tendo eles ou não).

* A troca de uma thread no modelo green é muito mais rapida doque em native

- O NATIVE-THREAD MODEL:

* Normalmente chamadas de System - level thread

* Usa as habilidades nativas do S.O. para gerenciar Sistemas multiThread. Faz como de threads processos.

* Permite TimeSlicing( Atraves do escalonador do S.O. Round-robin)

* São threads que obtem do S.O. nativo algumas funcionabilidades e ajudas no processamento.

* Usa o escalonador do Sistema operacional

* Dependendo de cada S.O. as native - threads trabalham de uma maneira diferente.

Qual a diferença entre Native e Green Model?

- ISSO EM LINUX

# Em threads Nativas, a troca de uma thread a outra fica a encargo do escalonador do S.O. (de processos ex: Round-robin) em Green model não temos timeSlicing conseqüentemente também não o Round-robin(ou seja em Green Model uma thread so passa para a outra se for explicitamente dito Thread.yield(), Object.wait(), etc. Ou bloqueando código...read() etc)

# Em maquinas com Múltiplas CPUs, threads nativas podem rodar simultaneamente em mais de uma CPU. No green Model todas as threads Rodam na mesma CPU.

#Threads Nativas dão aparência de muitos processos sendo executados: Cada thread tem a sua entrada na tabela de processos do S.O.

Um programador pode determinar se o S.O usará o modelo de green threads ou System threads?

Não. O usuário pode decidir a qual pacote escolher , porem uma vez executada a thread o usuário não pode alternar de green para system e vice versa.

Como posso programar de uma maneira que seja legal a ambos, Green e Native?

Tome algumas iniciativas de "manipulação" do Escalonador, do tipo use :

yield(), sleep (),wait(), noticy() etc...De uma maneira que você se responsabiliza pelo seus atos.

Como criar uma native thread?

A Jvm cria a thread chamando Apis de OS-level.

- De tudo que observamos sobre Green e System, vemos que a escolha do pacote realmente fará a diferença, porem a mais importante é conhecer o Sistema Nativo a qual o programa multiThread será executado, pois dai tiramos um embasamento pela arquitetura do S.O e das CPUs.

- A JVM não faz timeSlicing

- Porem o S.O pode suportar TimeSlicing - Através de algoritmos como o Round - robin

- Não faça programas que confiem em TimeSlicing

- Em muitos S.O. quando temos threads de mesma prioridade no Pool de Runnable, o a JVM implementa o uso Round-robin em alguns sistemas operacionais, outros usam outros modelo de thread, ou propriamente somente o de Prioridade.

- Sistemas operacionais como windows, não tem implementação do Green model, portanto todas as threads são vistas como native thread(ou seja todas as threads são tratadas como processo e como uma native thread). - toda thread em windows é tratada como native

- Em sistemas derivados de Unix(linux etc) pode-se implementar tanto green thread como native thread.

- Oque mudará se você terá green or native, é a implementação do seu código, e os packages que você usar.

- CPU Starvation(inanição) é quando uma thread fica no estado de RUNNABLE muito tempo e existe pouca possibilidade dela se tornar RUNNING, normalmente pela prioridade das outras threads que estão com ela.(a dela é menor que as outras.)

- Normalmente em threads de mesma prioridade a Jvm implementa o Round-robin do S.O.

- Existe uma API, java.util.concurrenty; ONDE TEMOS NOVAS IMPLEMENTAÇÕES PARA threads, alem de utilitários para a construção, REALMENTE VALE A PENA CONFERIR.

BOM voltaremos agora a Básicos threads 03...

CYA DUDES!!!