Básico sobre modelos de escalonamento 2:

Básico sobre modelos de escalonamento 2:

Green Threads:

O S.O não sabe nada sobre as threads do programa, a jvm encapsula tudo sobre as threads e é ela quem gerencia tudo .Visto do lado do S.O temos apenas um processo com apenas 1 thread.(mesmo que tenhamos "n" threads.)

Quando esta na hora da JVM, escalonar a mudança de uma thread para a outra, a JVM pega a thread que esta em Runtime salva todas as informações do estado dela, e então substitui-se pelo estado da nova thread, e as intruções que agora serão apontadas pelo pc do PC register são as da nova thread. NORMALMENTE ESSE MODELO É CHAMADO DE user-level threads PORQUE TUDO RODA DENTRO DO PROGRAMA, Não É NECESSARIO NENHUMA CHAMADA NATIVA AO S.O.

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 tambem é quem respresenta 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 ve oque esta ocorrendo e termina o programa antes que afete outros programas ou o próprio S.O.

Por causa dessa separação é possivel ter user leve threads, system level threads ou ambos independemente.

O green model é conhecido?

É o mais comum modelo inclusive usado em plugin no browser, muitas JVM implementam ele. AS THREADS FICAM DESCONHECIDAS perante AO S.O. JVMS QUE IMPLEMENTAM ESSE MODELO PODEM EXECUTAR SOMENTE UMA THREAD POR VEZ NA CPU, mesmo se tiver "n" Cpus.

ESCALONADOR DO GREEN MODEL COMO É?

Como discutimos aqui, Normalmente esse modelo é implementado em JVMS de plataformas derivadas do UNIX. Não temos então o round-robin, oque implica em não termos time-Slicing, ENTÃO fica somente a encargo da JVM. A JVM so tira uma thread de RUNNING, ou se uma thread de maior prioridade chegar, ou se a thread que estar em RUNNING se tornar BLOCKED. (ou wait() etc.)

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 Multiplas 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.

Pode um programador determinar se um programa usara green threads ou native threads?

source: http://www.javaworld.com/javaworld/javaqa/1999-10/02-qa-native.html

Não. O programador pode apenas decidir qual dos pacotes de thread usar quando o programa em java iniciar. Uma vez que o programa se iniciou, você não pode alternar de uma green para um native.

Isso significa que você deve escrever código que rodara sobre green como também sobre native. Código para threads Nativas é relativamente fácil de se implementar já que usa o escalonador do S.O, e todo S.O. garante que toda thread tem a chance de ser executada. Threads de prioridade alta frequentemente são executadas, enquanto threads de baixa prioridade raramente tem a chance, mais terão sua vez.

Por outro lado, green threads, Não dão muitas garantias. Se uma thread de alta prioridade estiver em um loop(CPU intensive) ou seja que nunca invoca nela sleep(),yield(),wait() ou algum código de bloqueio(ex: esperando por I/O) então threads de menores prioridade nunca serão executadas ate que a thread de alta prioridade termine o code_block de run(). A UNICA PROMESSA DAS GREEN THREADS É QUE UMA THREAD DE PRIORIDADE MAIS ALTA SEMPRE ESTARA EM RUNNING.

O real ponto é que, quando o programador pega a responsabilidade de influenciar o escalonador, seja da JVM(Green) ou da S.O(Round-robin ou seja outro) o programa multiThread dele funciona perfeitamente em qualquer S.O. em qualquer JVM. Tomar a responsabilidade pelas threads parece difícil, mais em muitos programas a maior parte das threads faz I/O com isso já da a chance a outras threas de pegarem sua vez.

A preocupação com o escalonador deve partir apenas quando temos thread CPU intensive. Nesses casos, chamando Thread.yield() damos a chance a uma thread de mesma prioridade de run().

Para dividir a CPU com uma thread de menor prioridade, a thread pode chamar Thread.sleep(), ou invocar wait() em uma objeto ate que a thread de mais baixa prioridade termine o code_block dela, e ao fim chame notify() que volta a thread de alta prioridade.