Michael Scott tem 34 anos como professor de Ciência da Computação na Universidade de Rochester e foi reitor por cinco anos na Universidade de Wisconsin-Madison. Ele está envolvido em pesquisas no campo da programação paralela e distribuída e design de idiomas e ensina isso aos alunos.

O mundo conhece Michael no livro Programming Language Pragmatics , e o trabalho Algorithms for synchronization scalable in multiprocessors de memória compartilhada ganhou o Prêmio Dijkstra como um dos mais famosos no campo da computação distribuída. Você também pode conhecê-lo como o autor desse algoritmo de Michael-Scott .

Juntamente com Doug Lee, ele desenvolveu esses algoritmos sem bloqueio e filas síncronas que executam as bibliotecas Java. A introdução de "estruturas de dados duplos" no JavaSE 6 permitiu uma melhoria de 10 vezes no desempenho do ThreadPoolExecutor .

Conteúdo:

• Início de carreira, Universidade de Rochester. Projeto Charlotte, Lynx;
• Interface coerente escalável IEEE, trava MCS;
• Sobrevivência em um mundo em constante mudança;
• Os alunos estão ficando mais burros? Tendências globais, internacionalização;
• Trabalho efetivo com os alunos;
• Como acompanhar a preparação de novos cursos e livros;
• A relação entre negócios e academia;
• Implementação prática de idéias. MCS, MS, CLH, JSR 166, trabalhando com Doug Lee e muito mais;
• Memória transacional;
• Novas arquiteturas. Vitória próxima da memória transacional;
• Memória não volátil, Optane DIMM, dispositivos ultra-rápidos;
• A próxima grande tendência. Estruturas de dados duplas. Hydra

Entrevistas realizadas por:

Vitaly Aksenov é atualmente pós-doca no IST Áustria e funcionário do Departamento de Tecnologia da Computação da Universidade ITMO. Envolvido em pesquisa na teoria e prática de estruturas de dados competitivas. Antes de ingressar no IST, ele recebeu um PhD da Universidade de Paris Didro e da Universidade de ITMO, sob a direção do Professor Peter Kuznetsov.

Alexey Fedorov é um produtor do JUG Ru Group, uma empresa russa que organiza conferências para desenvolvedores. Alexey participou da preparação de mais de 50 conferências e seu currículo contém tudo, desde o cargo de engenheiro de desenvolvimento na Oracle (JCK, Java Platform Group) até o cargo de um devrell em Odnoklassniki.

Vladimir Sitnikov é engenheiro do Netcracker. Há dez anos, ele trabalha no desempenho e na escalabilidade do NetCracker OS, um software usado pelas operadoras de telecomunicações para automatizar os processos de gerenciamento de rede e equipamentos de rede. Ele está interessado em questões de desempenho do Java e Oracle Database. O autor de mais de uma dúzia de melhorias de desempenho no driver oficial do PostgreSQL JDBC.

Início de carreira, Universidade de Rochester. Projeto Charlotte, linguagem Lynx.

Alexei : Para começar, eu queria dizer que na Rússia todos gostamos de ciência da computação, ciência de dados e algoritmos. Direito ao indecente. Todos lemos o livro Cormen, Leiserson e Rivest . Portanto, a próxima conferência, escola e esta entrevista em si devem ser muito populares. Recebemos muitas perguntas para esta entrevista de estudantes, programadores e membros da comunidade, por isso estamos muito gratos a você por esta oportunidade. A ciência da computação faz o mesmo amor nos EUA?

Michael : Nossa área é tão diversa, tem tantas direções e afeta a sociedade de várias maneiras que é difícil para mim responder-lhe inequivocamente. Mas o fato é que, graças a ela nos últimos 30 anos, houve tremendas mudanças nos negócios, na indústria, na arte e na sociedade como um todo.

Vitaliy : Vamos começar com algo distante. Em muitas universidades, há algo como especialização em uma área específica. Para a Universidade Carnegie Mellon, trata-se de computação paralela; para MIT, criptografia, robôs e multithreading. Existe essa especialização na Universidade de Rochester?

Michael : Para ser sincero, eu diria que o CMU e o MIT são especializados em todas as áreas. No nosso departamento, sempre foi dada mais atenção à inteligência artificial. Metade das pessoas que trabalham conosco está envolvida em IA ou interação homem-computador - essa proporção é maior do que em outros departamentos, e sempre foi. Mas quando eu estava na universidade, eu não tinha nenhum curso de IA e nunca trabalhei nessa área. Portanto, meu departamento é especializado em um problema com o qual não tenho nada a ver. O consolo é que o segundo problema mais importante para o nosso departamento é a programação paralela e multithread, ou seja, minha especialização.

Vitaliy : Você começou a estudar Ciência da Computação quando o campo da programação multithread já estava em sua infância. A lista de suas publicações mostra que os primeiros trabalhos diziam respeito a uma ampla gama de problemas: gerenciamento de memória em sistemas multithread, sistemas de arquivos distribuídos e sistemas operacionais. Por que tanta versatilidade? Você já tentou encontrar seu lugar na comunidade de pesquisa?

Michael : Como estudante, participei do projeto Charlotte da Universidade de Wisconsin, que desenvolveu um dos primeiros sistemas operacionais distribuídos. Lá, trabalhei com Raphael Finkel e Marvin Solomon. Minha dissertação foi dedicada ao desenvolvimento de uma linguagem para software de sistema para sistemas distribuídos - agora todos já se esqueceram disso e graças a Deus. Criei a linguagem de programação Lynx, que deveria simplificar a criação de servidores para um sistema operacional distribuído com ligação fraca. Como naquela época eu estava envolvido principalmente em sistemas operacionais, assumi que minha carreira estaria relacionada principalmente a eles. Mas a Universidade de Rochester era muito pequena e, por causa disso, diferentes grupos estavam se comunicando muito estreitamente. Não havia uma dúzia de outros especialistas em sistemas operacionais com quem eu pudesse me comunicar, portanto todos os contatos eram com pessoas que trabalhavam em áreas completamente diferentes. Gostei muito, ser generalista é uma grande vantagem para mim. Falando especificamente sobre estruturas de dados multithread e algoritmos de sincronização, comecei a lidar com eles completamente por acidente.

Interface Coerente Escalável IEEE, Bloqueio MCS.

Vitaliy : Você poderia dar um pouco mais de detalhes sobre isso?

Michael : Esta é uma história engraçada que eu nunca me canso de contar a todos. Aconteceu na conferência ASPLOS em Boston - foi no final dos anos 80 ou início dos anos 90. Participaram da conferência John Mellor-Crummey, um graduado de nossa faculdade. Eu o conhecia, mas antes disso não tínhamos conduzido pesquisas conjuntas. Mary Wernon, de Wisconsin, fez uma apresentação sobre o sistema multiprocessador desenvolvido em Wisconsin: Wisconsin Multicube . Nesse Multicube no nível de ferro, havia um mecanismo de sincronização chamado Q no Sync Bit, e mais tarde foi renomeado para Q no Lock Bit, porque poderia ser pronunciado como o nome do queijo Colby, ou seja, era um trocadilho. Se você está interessado em mecanismos de multithreading, provavelmente sabe que Colby acabou se tornando o mecanismo de sincronização do padrão IEEE Scalable Coherent Interface. Era um mecanismo de bloqueio que criava ponteiros de um cache para outro no nível de ferro, para que cada detentor da fechadura soubesse de quem era a vez. Quando John e eu ouvimos falar, nos entreolhamos e dissemos: por que fazer isso no nível do ferro? Você não pode fazer o mesmo com comparar e trocar? Pegamos um dos cadernos na platéia e abrimos um cadeado do MCS enquanto Mary continuava sua conversa. Mais tarde, implementamos, experimentamos, a ideia acabou sendo bem-sucedida e publicamos um artigo. Então, para mim, esse tópico parecia apenas uma distração divertida, após o qual planejei retornar aos sistemas operacionais. Porém, outro problema surgiu na mesma direção e, eventualmente, estruturas de sincronização, multithreading e dados se tornaram minha principal especialidade. Como você pode ver, tudo isso aconteceu por acaso.

Vitaliy : Eu conheço há muito tempo o bloqueio do MCS, mas até agora não sabia que esse é o seu trabalho e não entendi que é um acrônimo de seu sobrenome.

Como sobreviver em um mundo em constante mudança?

Alexei : Eu tenho uma pergunta sobre um tópico relacionado. 30 ou 40 anos atrás, havia mais liberdade em diferentes especialidades. Se você deseja iniciar uma carreira em sistemas multithreading ou distribuídos - por favor, deseja fazer sistemas operacionais - não há problema. Em cada área, havia muitas perguntas em aberto e poucos especialistas. Agora surgiram especializações restritas: simplesmente não há especialistas em sistemas operacionais em geral, existem especialistas em sistemas individuais. A mesma coisa com sistemas multithreading e distribuídos. Mas o problema é que nossas vidas não são infinitas, todos podem se dedicar à pesquisa apenas algumas décadas. Como sobreviver neste novo mundo?

Michael : Nós não somos especiais a esse respeito, o mesmo aconteceu uma vez em outras áreas. Eu tive sorte de ter começado a trabalhar na Ciência da Computação quando esse campo estava na era da "adolescência". Algumas fundações já haviam sido lançadas, mas tudo ainda era muito imaturo. Essa oportunidade aparece com pouca frequência. A engenharia elétrica existe há muito tempo, a física - ainda mais, a matemática - quase desde o início dos tempos. Mas isso não significa que na matemática ninguém mais faça descobertas interessantes. Ainda existem muitos problemas em aberto, mas ao mesmo tempo, mais precisa ser aprendido. Você observou corretamente que agora existem muito mais especializações do que antes, mas isso significa apenas que estamos na mesma situação que a maioria das outras áreas da atividade humana.

Alexei : Estou interessado no aspecto mais prático da questão. Eu tenho um ensino de matemática e, durante meus estudos, frequentemente participei de conferências e trabalhei em vários tópicos científicos. Eu descobri que ninguém na platéia entendeu meus relatórios e, da mesma forma, os relatórios de outras pessoas eram compreensíveis apenas para si mesmos. Em tópicos de alto nível, isso não é verdade, mas assim que você começa a se aprofundar em algo, o público deixa de acompanhar você. Como você lida com isso?

Michael : Nem sempre é bem sucedido. Recentemente, preparei um relatório em que me aprofundava em detalhes técnicos. À medida que o relatório avançava, ficou claro que a maioria do público não me entendia, então tive que me adaptar à situação em movimento. Os slides não puderam mais ser alterados, por isso não funcionou muito bem; portanto, de um modo geral, tento não usá-los. Em geral, meu conselho é este - considere seu público. Você precisa saber quem está entrando em contato, qual nível de conhecimento eles têm e o que precisam ouvir para avaliar seu trabalho.

Vitaliy : Você poderia dar uma dica sobre o que era essa palestra?

Michael : Para ser sincero, eu preferiria não falar sobre esse tópico para deixar anônimas as pessoas em questão. O ponto principal é que frequentemente mergulhamos profundamente nas sutilezas do problema em que estamos trabalhando, por isso fica difícil explicar no início do relatório por que esse problema é interessante e importante e como se relaciona às perguntas que os alunos já conhecem. De acordo com minhas observações, essa habilidade é mais difícil para os alunos. E esse foi o ponto fraco do meu relatório recente. Um relatório bem estruturado deve, desde o início, encontrar contato com o público, explicar exatamente qual é o problema e como ele se relaciona com tópicos já conhecidos. A forma como esta parte introdutória será técnica depende da audiência. Se estiver completamente manchado, o relatório poderá ter vários estágios. A entrada deve estar acessível a todos e, no final, parte pode não chegar a tempo para você, mas as pessoas que estão relativamente familiarizadas com a sua área poderão entender tudo.

Os alunos estão ficando mais burros? Tendências globais, internacionalização.

Alexei : Você acompanha estudantes há várias décadas. Os alunos ficam mais burros ou inteligentes de década para década ou de ano para ano? Na Rússia, os professores reclamam constantemente que os alunos estão ficando estúpidos todos os anos, e não está claro o que fazer a respeito.

Michael : Você pode realmente ouvir muita negatividade de nós, idosos. Inconscientemente, temos a tendência de esperar que os alunos dominem todos os 30 anos de experiência que já temos. Se tenho um entendimento mais profundo do que em 1985, por que os alunos não o têm? Provavelmente, porque eles têm 20 anos, como você gosta disso? Penso que as mudanças mais significativas nas últimas décadas dizem respeito à composição demográfica: agora temos significativamente mais estudantes internacionais, com exceção dos canadenses. Havia muitos canadenses, já que estamos muito perto da fronteira com o Canadá, e os estudantes podem voltar para casa nos fins de semana. Mas agora no Canadá existem muitas boas universidades, e os canadenses preferem estudar em casa, nos EUA começaram a viajar muito menos.

Alexei : Você acha que essa é uma tendência local ou global?

Michael : Não me lembro exatamente quem, mas alguém disse que o mundo é plano. Nossa área se tornou muito mais internacional. As conferências da ACM costumavam ser realizadas exclusivamente nos EUA, então eles decidiram realizá-las a cada 4 anos em outros países e agora são realizadas em todo o mundo. Em maior medida, essas mudanças afetaram o IEEE , pois sempre foi uma organização mais internacional que o ACM. E os gerentes de programas (presidentes de programas) são da China, Índia, Rússia, Alemanha e muitos outros países, porque em todo lugar muitas coisas estão acontecendo agora.

Alexei : Mas provavelmente existem alguns aspectos negativos dessa internacionalização?

Michael : Eu diria que todos os aspectos negativos não são sobre tecnologia, mas sobre política. O problema principal foi o fato de os Estados Unidos terem roubado as pessoas mais inteligentes e talentosas de países ao redor do mundo. E agora o principal problema são os jogos políticos entre diferentes países em torno de vistos e imigração.

Alexei : Ou seja, barreiras e coisas do gênero. Eu vejo.

Vladimir : Pessoalmente, eu me pergunto qual abordagem você adota ao ensinar uma nova matéria para os alunos. Afinal, existem opções diferentes: você pode primeiro tentar inspirá-los a experimentar algo novo e prestar mais atenção aos detalhes de como uma determinada tecnologia funciona. O que você prefere?

Trabalho eficaz com os alunos

Alexei : E como encontrar o maldito equilíbrio entre o primeiro e o segundo?

Michael : O problema é que as aulas nem sempre são como eu gostaria. Normalmente, dou aos alunos a leitura antecipada do material, para que eles se aprofundem, entendam o máximo possível e formulo perguntas nos lugares que não conseguiram entender. Depois, na sala de aula, você pode se concentrar nos momentos mais difíceis e explorá-los todos juntos. É assim que eu mais gosto de liderar aulas. Mas, levando em consideração a carga que está atualmente sobre os alunos, nem sempre consigo garantir que eles sejam preparados com antecedência. Como resultado, temos que dedicar muito mais tempo à recontagem geral do material do que gostaríamos. Apesar disso, tento manter nossas aulas interativas. Caso contrário, é mais fácil gravar um vídeo uma vez, para que os alunos possam assistir em casa. O significado de atividades vivas está na interação humana. Na sala de aula, prefiro não usar slides, mas giz e um quadro-negro, exceto em alguns casos em que algum diagrama é muito complicado para ser desenhado em um quadro-negro. Graças a isso, não preciso seguir um plano de aula rigoroso. Como não há uma ordem estritamente definida na qual forneço o material, isso me permite adaptar-me ao público, dependendo das perguntas que recebo. Em geral, tento tornar as aulas o mais interativas possível, para que o material que apresento dependa das perguntas que me são feitas.

Vladimir : Isso é muito legal. Na minha experiência, é bastante difícil receber perguntas do público. Mesmo se você pedir com antecedência para fazer alguma pergunta, não importa estúpido ou inteligente, eles ainda estarão em silêncio. Como você lida com isso?

Michael : Você vai rir, mas se você ficar em silêncio por um longo tempo, mais cedo ou mais tarde todos ficarão desconfortáveis ​​e alguém fará uma pergunta. Ou você pode fazer uma pergunta técnica simples com a resposta "sim" ou "não" para determinar se as pessoas entenderam o que foi discutido. Por exemplo, há uma corrida de dados no exemplo acima? Quem pensa que sim? Quem pensa que não? Quem não entende nada, porque no total apenas metade das mãos se levantou?

Vitaliy : E se você respondeu incorretamente, sai da classe :-)

Michael : Se você não respondeu nada, faça uma pergunta. Devo entender o que exatamente o aluno precisa saber para responder à pergunta que acabei de fazer. Eles precisam me ajudar a ajudá-los. Estou pronto para me adaptar a eles para que eles entendam o problema. Mas se eu não sei o que está acontecendo na cabeça deles, não posso fazer isso. E se você não dá aos alunos paz por um longo tempo, então no final eles às vezes fazem as perguntas certas, ou seja, aquelas que me ajudam a ver o que está acontecendo na cabeça dos alunos.

Alexei : Às vezes, essas perguntas suscitam idéias nas quais você nunca tinha pensado antes? Eles são inesperados? Eles nos permitem olhar para algum problema sob uma nova luz?

Michael : Há perguntas que abrem uma nova maneira de apresentar material. Muitas vezes, existem perguntas que levam a problemas interessantes sobre os quais não planejei falar. Os alunos costumam me dizer que tenho uma tendência a me afastar do tópico da lição quando isso acontece. E, segundo eles, muitas vezes essa é a parte mais interessante da atividade. Muito raramente, literalmente várias vezes, os alunos faziam perguntas que surgiam com uma nova direção no estudo e se transformavam em um artigo. Isso acontece com muito mais frequência nas conversas com os alunos, e não durante as aulas, mas ocasionalmente durante as aulas.

Alexei : Ou seja, os alunos fizeram perguntas, com base nas quais você poderia publicar um artigo mais tarde?

Michael : Sim.

Vitaliy : Com que frequência você mantém essas conversas com os alunos? , ?

: — . - 5 6 , - . , — . , . , . , . , , . , , , .

: ? , — .

: , — , . . , , . , , 9 17 . , , — .

.

: - , ? - Computer Science.

: , — .

: , 10, 20, 30 ? , , .

: , . 1980-, , ( Doug Baldwin ). , , . , . ( : «Programming Language Pragmatics» ) 200 . , , . , : , , , . , , . , Pascal, . Swift, Go, Rust, , . , , , . Python, Ruby Perl, , , , .

: . ? , — , . ?

: , 100% . , — . Rust, Google, Mozilla . , . , .

: . (cache coherence). , ? . ?

: , . ( William Bolosky ) ( Leonidas Kontothanassis ) 1990- . , : , , , . . , NUMA, page placement . , , — . , (hardware transactional memory). , , . , , . , .

: : , ? ?

: , , . , . , , . , , - . , - - , . . - , , . — .

: . , . , , Intel. , ?

: , , , - . , : , , . , , , . , , , , . , , . , . , . - 15 . , , «How to evaluate systems research» - , . , , , , . , .

: , , . , , TDP, . ? , ?

: , . , . , , . , Linux. , AWS. .

: ? ?

: . - 1980- , . , (National Science Foundation ) (Coordinated Experimental Research, CER). Computer Science, . 1984 128- BBN Butterfly, . . 128 , , . , 128 . MCS.

: , ?

: — . : -, , , . - 10 , - . Intel. , , , . , ( Steven Swanson ) . , . , . , , , .

. MCS, MS, CLH, JSR 166, .

: , . MCS - (MS) , Java. ( : ). CLH , . .

: , 10 .

: Java?

: . , ? ?

: , MS Java 5. (Mark Moyers) Sun Microsystems . , , , . (Doug Lea). , - 25 Sun JSR 166 , java.util.concurrent. , MS, . , , . , . , « », . , . Java.

: , .size() , O(1)?

: , .

: .size() Java, , , . , .

: (dual data structures) (Bill Scherer) — , Hydra . , Java Executor Framework. , (fair and unfair queues). , . executors .

: ? , . , , , , , - . ?

: , « » — , . , . , K42 IBM MCS , acquire release. , , . , , , . , .

, . , MS , , CAS. CAS . Intel , - 30 , . , MS, . , O(n) , O(1). , . - , . , . , , , , . . (Dave Dice) Oracle. , , , . NUMA-aware .

: , . - , , , . .

: , . , , . , . , 10, 20, 25 . , . , , , , . , . , . , , 10 . — 20. , . . , . (Joe Izraelevitz) DISC, , . , , . , . , , .

: - , ? , ? , , , .

: , , . -, , Google Scholar , , . , . , , , — . . , , , . , , .

: , ?

: , , . , , . , , . , (M. Herlihy, JEB Moss) . 1990- , , , . , JSR 166. , . 2000-, . . . . , , .

: . , , . , . , , , . ( : — , Disruptor Aeron . Joker 2015, YouTube . , ). , , . . ?

: : , .

: , .

: — . , . (Butler Lampson), « ». . , , 10 — . ISA , , . . , . — GPU, , , , FPGA. , ? , .

: , . , . : — , , — , , , .

: — - .

: C++.

: - (Hans Boehm). , , . , . , , , 30 . ( : ).

: : ?

: . , , API. API, . , . . , , , , .

: , , , , , ? , , . , . ?

: . , , , - . , , . MNS . (Adam Morrison) (Yehuda Afek) LCRQ . , , fetch-and-increment. . , fetch-and-increment . (Eric Freudenthal) Ultracomputer c (Allan Gottlieb) 1980-, . fetch-and-increment .

. ?

: , ?

: , , , .

: , ?

: — Intel IBM. , - load store . happens-before, . , , , . , , .

— . , . . , , 100 , , . , , . , - .

: , . ?

: . — . , — . , . , , , . , . , , . . , CAS , , . , , .

, Optane DIMM, .

: , — : . ? , - ?

: , , . , Intel Optane DIMM , - 3 10 , RAM. . , RAM. , 10 , DRAM — . . , - . , - , — . , , . . , , . , , , «» .

, — . . - , , 5 , TCP-IP , . . , , . , . USENIX ATC . , , , I/O, . , .

: — , — . , .

: .

: , ?

: , - . , , . , , - . , .

: . , RAM CPU. - RAM .

: . , . .

: , . .

: . .

: .

. Dual data structures. Hydra.

: , . , , . , ? , , ?

: , . , , - . - , , , . , .

: Hydra . , , . ?

: . , . , , Java. , , . , , , , . , . , — , , . . , 10 , - , . - , . «» , , , -. - , . . , , , . , .

: ? , ?

: , , -, , , -, , , . , , . . , . , .

: : , ?

: , . , , , . , . , . , - MS.

: ?

: , . Hydra. , Java, LCRQ, .

: , Hydra — , - ?

: , , Hydra , Java, , .

: , .

: , .

: , : .

: , ? ?

: , , . , . , . , SPTDC; - Java, -, Java. Java, .

: , Hydra - , , - . , . , , . , . Muito obrigado!

: .

: -.

: , . - ?

: , . - , , , .

: , . , !

Hydra 2019, 11-12 2019 -. «Dual data structures» . .