Ambientes de Execuo

Concorrncia entre
Threads Java

Ambientes Java

Estrutura da JVM (Java)

Carregador de Classes Java

Estruturas de Dados da JVM

Ambiente de Execuo do
Java
Run Time Environment
Como estruturado ???
Implementado pelas APIs da
linguagem.

Arquiteturas de Kernel

Arquitetura do kernel Linux

Kernel Monoltico !!!!
Todas as suas funes (acesso e gravao nos
sistemas de arquivos, operaes de entrada
e sada, gerenciamento de memria, e
escalonamento de processos) so realizadas
no espao do prprio Kernel,
Ou seja, so todas realizadas em um nico bloco
com todas as funcionalidades bsicas carregadas
na memria.

Estrutura Linux

Arquitetura GNU Linux

Arquitetura GNU Linux outra viso

Espao do Usurio (EU)

Este o espao no qual os aplicativos de usurio
so executados.
GNU C Library = glibc
EU = Aplicaes do Usurio + GNU C Library
Aplicaes Java do Usurio = Multithreading
(Java
Threads)

GNU C Library (glibc)

Fornece a interface de chamada do
sistema que se conecta ao kernel e
fornece o mecanismo para transio
entre o aplicativo de espao de
usurio e o kernel.
Isso importante, pois o kernel e o
aplicativo do usurio ocupam
espaos de endereos diferentes e
protegidos.

Espaos de Endereamento

Embora cada processo no espao de

usurio ocupe seu prprio espao de
endereamento, o kernel ocupa um
nico espao de endereo.

Interfaces Externas ao
Kernel Linux
C Library ou GNU C Library
System Call Interface - SCI
(Chamadas do Sistema)
Como a JVM se comunica com a
SCI ??

Chamadas de Sistema (SCI)

Interface de programao aos servios fornecidos pelo SO.

Tipicamente escritos em uma linguagem de alto nvel (C or

C++).

Geralmente acessadas por programas via uma API

(Application
Program Interface) do que diretamente pelo uso de
chamadas de
sistema.

Trs APIs mais comuns so :

Win32 API para Windows.
POSIX API para sistemas baseados em POSIX (incluindo
todas as verses de UNIX, Linux, e Mac OS X).
Java API para a mquina virtual Java (JVM).

Exemplo de Concorrncia
Um exemplo simples pode ser expressado atravs de
um jogo onde o mesmo pode ser modelado com linhas
de execuo diferentes (threads distintas), sendo uma
para desenho de imagem e outra para udio;
Neste caso, h um thread para tratar rotinas de
desenho e outro thread para tratar udio;
No ponto de vista do usurio, a imagem desenhada
ao mesmo tempo em que o udio emitido pelos altofalantes; Porm, para sistemas com uma nica CPU,
cada linha de execuo processada por vez;

Escalonamento de Threads
Da mesma forma que os processos sofrem
escalonamento, as threads tambm tm a mesma
necessidade.
Quando vrios processos so executados em uma
CPU, eles do a impresso que esto sendo
executados simultaneamente.
Com as threads ocorre o mesmo, elas esperam at
serem executadas. Como esta alternncia muito
rpida, h impresso de que todas as threads so
executadas paralelamente.

ULT e KLT

Usualmente as threads so divididas

em duas categorias:
thread ao nvel do usurio (em ingls
: User-Level Thread (ULT)),
thread ao nvel do ncleo (em ingls:
Kernel-Level Thread (KLT)).

Escalonamento de Threads
no Espao do Usurio (ULT)
Linha de execuo ao nvel do usurio
As threads ULT so escalonadas pelo
programador, tendo a grande vantagem de cada
processo usar um algoritmo de escalonamento que
melhor se adapte a situao. O sistema operacional
neste tipo de thread no faz o escalonamento, em
geral ele no sabe que elas existem.
Neste modo, o programador responsvel por
criar, executar, escalonar e destruir a thread.

Threads no Nvel Usurio

Threads em modo usurio so implementas por
chamadas a uma biblioteca de rotinas que so
ligadas e carregadas em tempo de execuo
(run-time) no mesmo espao de
endereamento do processo e executadas em
modo usurio.
O sistema operacional no sabe da existncia
de mltiplos threads, sendo responsabilidade
da biblioteca gerenciar e sincronizar os
diversos threads existentes.

Threads no Nvel Usurio

Utilizando a biblioteca, mltiplos threads poder ser
utilizados, compartilhando o mesmo espao de
endereamento do processo e outros recursos.
Threads em modo usurio so rpidos e eficientes,
por dispensar acesso ao kernel do sistema para
a criao, eliminao, sincronizao e troca de
contexto das threads. A biblioteca oferece todo o
suporte necessrio em modo usurio, sem a
necessidade de chamadas ao sistema (system
calls).

Processos e suas Threads

ULT

Exemplo ULT
Um exemplo prtico de processo chamado P1 que
contm tais threads: P1-T1, P1-T2 e P1-T3, quando o
sistema operacional d CPU para o processo P1, cabe
a ele destinar qual thread ser executada.
Caso esta thread use todo o quantum para o processo,
o sistema operacional chamar outro processo, e
quando o processo P1 voltar a executar, P1-T1 voltar a
ser executada e continuar executando at seu trmino
ou interveno de P1, este comportamento no afetar
outros processos pois o sistema continua escalonando
os processos normalmente.

Threads no Nvel do Usurio

As threads da primeira categoria (ULT) so
suportadas pela aplicao, sem conhecimento
do ncleo e geralmente so implementadas por
pacotes de rotinas (cdigos para criar, terminar,
escalonamento e armazenar contexto)
fornecidas por uma determinada biblioteca de
uma linguagem.
Multithreading em Java.
Como o caso da thread.h (biblioteca padro
da linguagem C)

Threads no Nvel de Kernel

Linha de execuo ao nvel do ncleo
As KLT so escalonadas diretamente pelo sistema
operacional, comumente so mais lentas que as
Threads ULT pois a cada chamada elas necessitam
consultar o sistema, exigindo assim a mudana total de
contexto do processador, memria e outros nveis
necessrios para alternar um processo.
Um exemplo prtico de processo chamado P2 que
contm as threads P2T1, P2T2 e P2T3 e um processo
chamado P3 que contm as threads P3T1, P3T2 E P3T3.

Escalonamento de Threads
O Sistema Operacional no entregar a CPU ao
processo e sim a uma thread deste processo.
Note agora que o sistema responsvel por
escalonar as threads e este sistema tem que
suportar threads, a cada interrupo de thread
necessrio mudar todo o contexto de CPU e
memria, porm as threads so independentes
dos processos, podendo ser executadas P3T2,
P2T1, P2T2, P2T1, P3T1,P2T3,P3T3, ou seja a
ordem em que o escalonador do sistema
determinar.

Threads no Nvel Usurio

J com as threads em modo usurio no se
consegue ter a mesma independncia, pois
quando passamos o controle ao processo,
enquanto seu quantum for vlido ele ir decidir
que thread ir rodar.
Um escalonamento tpico do sistema onde o
escalonador sempre escolhe a thread de maior
prioridade, que so divididas em duas classes:
Real Time e Normal.

Prioridades de Threads
Cada thread ganha uma prioridade ao ser
criada que varia de 0 a 31(0 a menor e
31 maior), processos com prioridade 0 a
15 (Real Time) tem prioridade ajustada no
tempo de execuo como nos processos
de E/S que tem a prioridade aumentada
variando o perifrico.

Prioridades de Threads
Processos com prioridade 16 a 31 so executados
at terminar e no tem prioridade alterada, mas
somente uma thread recebe a prioridade zero que
a responsvel por zerar pginas livres no
sistema.
Existe ainda uma outra classe chamada de idle,
uma classe mais baixa ainda, que s executada
quando no existem threads aptas, threads dessa
classe no interferem na performance.

Processos e Threads KLT

Escalonamento de Threads
Por Prioridade
Por Fracionamento de Tempo do
processador (Time-Slicing)

Preempo
Ato de forar a execuo de uma
thread parar de executar no
processador.
Precisa de chamadas ao sistema
(SCI).

Por Prioridade

Cada thread Java tem uma prioridade

(mnima = 0 e mxima=10), que ajuda ao
SO a determinar a ordem em que as
threads so escalonadas para execuo no
processador.
Uma vez que uma thread de maior
prioridade ganhe o processador, ela
executa at sua concluso.

Time-Slicing
Fracionamento de tempo de CPU
(Time-Slicing)
Mesmo que a thread no tenha
concludo a execuo quando o
quantum de tempo expirar, o
processador tirado da thread e recebe
a prxima de igual prioridade, se
houver alguma disponvel.

Time-Slicing
Time-Slicing preemptivo, mas
preempo no implica em TimeSlicing.
A maioria das plataformas Java
suporta Time-Slicing.

O que um Kernel
Um kernel, na verdade, no nada mais
do que um gerenciador de recursos.
Se o recurso que est sendo gerenciado
for um processo, uma memria ou um
dispositivo de hardware, o kernel gerencia
e intermedia o acesso ao recurso entre os
vrios usurios concorrentes (no kernel e
no espao do usurio).

Kernel Linux
O kernel Linux implementa vrios
atributos importantes de arquitetura.
O kernel dividido em camadas de
diversos subsistemas distintos.
O Linux pode tambm ser considerado
monoltico porque agrupa todos os
servios bsicos dentro do kernel.

Subsistemas do Kernel

Subsistemas do Kernel

Estados de Processos no
Nvel de Kernel Linux

Sistema de Arquivos Virtual

Sistema de Arquivos Virtual

Sistema de Arquivo Virtual

O Sistema de Arquivo Virtual (VFS)
fornece uma abstrao de interface
aos sistemas de arquivos.
O VFS fornece uma camada de troca
entre a SCI e os sistemas de arquivos
aos quais o kernel oferece suporte.

Pilha de Rede
A pilha de redes, pela estrutura, segue uma
arquitetura em camadas.
O Protocolo de Internet (IP) o protocolo
principal de camadas de rede situado abaixo
do protocolo de transporte (mais comumente o
Protocolo de Controle de Transmisses ou TCP).
Acima do TCP est a camada de soquetes, que
chamada pelo SCI.

Pilha de Rede
A camada de soquetes a API padro para o
subsistema de rede e fornece uma interface
com o usurio para vrios protocolos de rede.
Desde o acesso a quadros da camada 2 s
unidades de dados de protocolo IP (PDUs) e
at o TCP e o User Datagram Protocol (UDP),
a camada de soquetes fornece um modo
padronizado de gerenciar conexes e mover
dados entre terminais.

Arquitetura e
Implementao
Threads em Modo Usurio
Threads em Modo Kernel
Threads em Modo Hbrido

Threads em Modo Hbrido

Desvantagens do Modo Usurio e do

Modo Kernel.
Nesta arquitetura existe a idia de
combinar as vantagens de threads
implementados em modo usurio e
modo kernel.

Threads em Modo Hbrido

Modelo Muitos-Para-Um
Modelo Um-Para-Um
Modelo Muitos-Para-Muitos

Modelo Muitos-Para-Um

- O modelo muitos-para-um mapeia muitos threads

de nvel de usurio para threads do kernel.
O gerenciamento dos threads realizado no
espao do usurio e assim eficiente, mas o
processo inteiro ficar bloqueado.
Alm disso, como somente um thread pode
acessar o kernel de cada vez, mltiplos threads
so incapazes de executar em paralelo em
multiprocessadores.

Modelo Um-Para-Um
O modelo um-para-um mapeia cada thread de
usurio para um thread de kernel, gera mais
concorrncia do que o modelo muitos-para-um.
Permite a um outro thread ser executado, enquanto
um thread realiza uma chamada de sistema de
bloqueio, ele tambm permite que mltiplos threads
executem em paralelo em multiprocessadores.
A nica desvantagem deste modelo que a criao
de um thread de usurio requer a criao do
correspondente thread de kernel.

Modelo Muitos-Para-Muitos
- O modelo muitos-para-muitos multiplexa muitos threads de nvel
de usurio para um nmero menor ou igual de threads de kernel.
O nmero de threads de kernel pode ser especfico tanto para uma
aplicao em particular quanto para uma mquina em particular.
Os desenvolvedores podem criar tantos threads de usurio
quantos forem necessrios, e os correspondentes threads de
kernel podem executar em paralelo em um multiprocessador.
Alm disso, quando um thread realiza uma chamada de sistema
de bloqueio, o kernel pode agendar um outro thread para
execuo.

Multiprocessamento
Multiprocessamento a capacidade de um
sistema operacional executar simultaneamente
dois ou mais processos. Pressupe a existncia
de dois ou mais processadores.
Difere da multitarefa, pois esta simula a
simultaneidade, utilizando-se de vrios
recursos, sendo o principal o
compartilhamento de tempo de uso do
processador entre vrios processos.

Caractersticas do Multiprocessamento
Um multiprocessador ou sistema multiprocessado um sistema integrado de
computao com as seguintes caractersticas:
Envolve dois ou mais processadores fsicos:
sejam processadores separados;
mltiplos ncleos encapsulados no mesmo chip);
lgicos (processador(es) com a tecnologia HyperThreading da Intel) com o mesmo poder
computacional e cada um capaz de executar processos autonomamente.
Isto implica que no h nenhuma unidade central de controle; cada processador contm sua prpria
unidade de controle.
Assim, efetivamente, a lgica de controle distribuda pelo sistema.

Os processadores compartilham um nico espao de endereamento de memria.

O sistema de hardware como um todo gerenciado por um nico sistema operacional.
O sistema operacional com suporte a multiprocessamento deve ser capaz de:
suportar multitarefa;
manter mltiplas filas de processos, uma para cada processador.