gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
2.6 Scheduler e MySQL 5.0
Contribuído por scorpio em 27-12-03 16:18
do departamento christmas-news
Rapidinhas vd escreve "A arstechnica, publicou um artigo sobre o novo scheduler do kernel 2.6.
O artigo não só explica como o novo scheduler funciona, mas também fala sobre as novas funcionalidades desde o 2.4 e como elas são importantes.

Por outro lado, na vespera de natal o MySQL lançou uma nova versão, a 5.0 (Alfa).
Esta nova versão já possui suporte básico para stored procedures usando as especificações SQL-99, semelhante ao Oracle. Suporte elementar para cursores e alguns melhoramentos na velocidade. "

Opensource: quem vai para o mar avia-se em terra! | Wi-FI Tracker  >

 

gildot Login
Login:

Password:

Referências
  • Linux
  • arstechnica
  • artigo sobre o novo scheduler do kernel 2.6
  • MySQL
  • 5.0 (Alfa)
  • Mais acerca Rapidinhas
  • Também por scorpio
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    ai ai ai (Pontos:1)
    por ruben dig em 27-12-03 17:05 GMT (#1)
    (Utilizador Info) http://www.floppy.com.pt
    "This attribute is called "thread affinity;" a thread is simply another name for a process." ups alguém vai chumbar a SO :)
    Re:ai ai ai (Pontos:1, Redundante)
    por scorpio em 27-12-03 18:49 GMT (#2)
    (Utilizador Info) http://eurotux.com/
    Nem por isso... com os mecanismos de copy-on-write, uma thread pode ser um processo grande parte do tempo....
    Re:ai ai ai (Pontos:3, Esclarecedor)
    por m3thos em 27-12-03 22:11 GMT (#5)
    (Utilizador Info) http://mega.ist.utl.pt/~mmsf
    não.

    com copy on write ou não, o que interessa são as garantias que:

    threads partilham dados, code, file descriptors, ambiente... Tudo menos thread context e stack.
    Inclusivé o PID

    processos não, processos com copy-on-write, partilham, por motivos de optimização até alguma escrita, alguns destes recursos.
    Mas uma thread é por definição: um "lightweith process"

    o que tu podias dizer, é que um processo pode ser uma nova thread grande parte do tempo(até 'a copia..).

    Além disso, o comportamento de varios processos versus um processo multithreaded com signals é significativamente diferente.

    acho que realmente, o editor era capaz de xumbar em OS, embora os seus conhecimentos de microprocessadores lhe pudessem garantir uma boa nota nessa cadeira.. mas em OS.. :-/

    qualquer professor de SO deveria exigir que se ficasse ciente que uma thread é um "lightweight process".

    Até em muitos sistemas operativos, e em linux inclusivé, o que é corrido e gerido pelo scheduler são "tasks" ou "threads" tendo os processos pelo menos uma "task" ou "thread".

    p.s.: uma cena parva que não percebo porque se mantém no linux 2.6 é porque raio threads do mesmo processo têm PIDs diferentes. tal não deveria acontecer.


    Miguel F. M. de Sousa Filipe
    handle: m3thos
    More Human than Human.

    Re:ai ai ai (Pontos:2)
    por racme em 28-12-03 2:49 GMT (#6)
    (Utilizador Info) http://vendetta.guildsoftware.com
    acho que realmente, o editor era capaz de xumbar em OS, embora os seus conhecimentos de microprocessadores lhe pudessem garantir uma boa nota nessa cadeira.. mas em OS.. :-/

    qualquer professor de SO deveria exigir que se ficasse ciente que uma thread é um "lightweight process".


    Todos nos aprendemos pelos mesmos livros, e acho que ele nao e' assim tao diferente





    Those who do not understand Unix are condemned to reinvent it, poorly.
    -- Henry Spencer
    Re:ai ai ai (Pontos:2)
    por scorpio em 28-12-03 17:33 GMT (#7)
    (Utilizador Info) http://eurotux.com/
    Obrigado por me dares razão.
    Re:ai ai ai (Pontos:2)
    por JohnnyBigodes em 28-12-03 19:24 GMT (#8)
    (Utilizador Info)
    p.s.: uma cena parva que não percebo porque se mantém no linux 2.6 é porque raio threads do mesmo processo têm PIDs diferentes. tal não deveria acontecer.

    Bem... ocorrem-me duas coisas:

    - poderes fazer kill ou de outra forma manipular (nice, p.ex.) uma thread específica.
    - se o PID também é exactamente o identificador usado internamente, está automaticamente explicado porque é que é diferente.
    Re:ai ai ai (Pontos:2)
    por raxx7 em 28-12-03 20:52 GMT (#10)
    (Utilizador Info)
    A questão dos PIDs têm a ver com limitações antigas.
    Continua a manter-se por não depende só do kernel mas também da libpthread que usas. Com NPTL deixas de ter esse comportamento.

    Remember to be the Killer, not the Victim! (Nuklear Girl)
    Re:ai ai ai (Pontos:3, Interessante)
    por techn0id em 27-12-03 19:13 GMT (#3)
    (Utilizador Info)
    Na verdade, parece-me que o autor queria dizer "processor affinity" ao inves de "thread affinity" ou mesmo "process affinity". A ideia e' que um processo tem uma determinada afinidade por um determinado processador no sistema.

    -- prla
    Re:ai ai ai (Pontos:3, Esclarecedor)
    por raxx7 em 28-12-03 20:48 GMT (#9)
    (Utilizador Info)
    Neste caso, são mesmo as threads/tasks que têm afinidade por um processador. Diferentes threads do mesmo processo podem ter afinidade por processadores diferenes.

    Remember to be the Killer, not the Victim! (Nuklear Girl)
    Re:ai ai ai (Pontos:1, Lança-chamas)
    por JohnnyBigodes em 27-12-03 20:13 GMT (#4)
    (Utilizador Info)
    Tu também és muito ranhoso... :)
    Scheduler - Excelente Algoritmo (Pontos:1)
    por dmaster em 29-12-03 14:47 GMT (#11)
    (Utilizador Info)
    Ver as especificações do kernel 2.6, particularmente os detalhes sobre a implementação do novo scheduler optimizado é fantástico. Aqui temos um sistema operativo com 13 anos, e uma das suas componentes mais importantes como a da gestão de processos é de repente alvo de uma boa dose de raciocínio "look at the big picture" e como resultado temos uma melhoria substancial de todo o sistema.

    Como programador, acho genial assistir mais uma vez aos velhos dogmas de implementação caírem por terra e o engenho e arte brotarem como que por inspiração divina!

    Deliciei-me ao ver o uso elegante das estruturas bitmap e das novas filas de prioridade. Tenho visto muito bom código mas este deu-me o tal "zen feeling" e remeteu-me pessoalmente a outros tempos onde o K e o Mhz estava na hora do dia. Parabéns!

    Agora, pergunto-me como está implementado o kernel dos outros 'nixs por aí? E o scheduler do NT? Como será; terá sofrido alterações de monta desde os tempos da IBM? Tannenbaum, ele próprio, quantas vezes parou para re-pensar neste tópico?

    E melhor pergunta ainda; Quantos e-mail internos na Microsoft estarão agora a serem trocados com a expressão O(1) neles? :-]
    Re:Scheduler - Excelente Algoritmo (Pontos:2)
    por racme em 29-12-03 20:17 GMT (#12)
    (Utilizador Info) http://vendetta.guildsoftware.com
    Agora, pergunto-me como está implementado o kernel dos outros 'nixs por aí?

    em freebsd tens o ULE desde a 5.1 options SCHED_ULE
    que vai passar a default scheduler qd sair a 5-STABLE



    Those who do not understand Unix are condemned to reinvent it, poorly.
    -- Henry Spencer

     

     

    [ Topo | Sugerir artigo | Artigos anteriores | Sondagens passadas | FAQ | Editores | Preferências | Contacto ]