- como profesor de Ciencias da Computación na Universidade de Rochester, e na súa universidade natal de Wisconsin-Madison foi decano durante cinco anos. Investiga e ensina aos estudantes sobre programación paralela e distribuída e deseño de linguaxes.
O mundo coñece a Michael polo libro de texto , e o traballo recibiu o Premio Dijkstra como un dos máis famosos no campo da computación distribuída. Tamén podes coñecelo como o autor dese mesmo algoritmo .
Xunto con Doug Lee, desenvolveu os algoritmos sen bloqueo e as colas síncronas que alimentan as bibliotecas de Java. Implementación en JavaSE 6 mellorou o rendemento 10 veces ThreadPoolExecutor.
Contido:
- Carreira inicial, Universidade de Rochester. Proxecto Charlotte, lingua Lynx;
- Interfaz coherente escalable IEEE, bloqueo MCS;
- Supervivencia nun mundo en constante cambio;
- Os estudantes están a ser máis tontos? Tendencias globais, internacionalización;
- Traballo eficaz co alumnado;
- Como estar ao día coa preparación de novos cursos e libros;
- Vínculos entre empresas e academia;
- Aplicación práctica de ideas. MCS, MS, CLH, JSR 166, traballando con Doug Lee e moito máis;
- Memoria transaccional;
- Novas arquitecturas. A vitoria da memoria transaccional está preto;
- Memoria non volátil, Optane DIMM, dispositivos ultrarrápidos;
- A próxima gran tendencia. Estruturas de datos duais. Hidra.
As entrevistas son realizadas por:
Vitali Aksenov — actualmente posdoctorado en IST Austria e membro do Departamento de Tecnoloxías Informáticas da ITMO University. Realiza investigacións no campo da teoría e práctica das estruturas de datos competitivas. Antes de traballar en IST, recibiu o seu doutoramento na Universidade Paris Diderot e na Universidade ITMO baixo a supervisión do profesor Peter Kuznetsov.
Alexei Fedorov é produtor de JUG Ru Group, unha empresa rusa que organiza conferencias para desenvolvedores. Alexey participou na preparación de máis de 50 conferencias e o seu currículo contén desde o posto de enxeñeiro de desenvolvemento en Oracle (JCK, Java Platform Group) ata o posto de programador en Odnoklassniki.
Vladimir Sitnikov é enxeñeiro en Netcracker. Desde hai dez anos traballa no rendemento e escalabilidade do sistema operativo NetCracker, software que utilizan os operadores de telecomunicacións para automatizar os procesos de xestión de equipos de rede e redes. Interesado en problemas de rendemento de Java e Oracle Database. Autor de máis dunha ducia de melloras de rendemento no controlador JDBC oficial de PostgreSQL.
Carreira inicial, Universidade de Rochester. Proxecto Charlotte, lingua Lynx.
Alex: Para comezar, quería dicirvos que en Rusia a todos nos encanta a informática, a ciencia de datos e os algoritmos. É francamente obsceno. Lemos todo . Polo tanto, a próxima conferencia, a escola e esta propia entrevista deberían ser moi populares. Recibimos moitas preguntas para esta entrevista de estudantes, programadores e membros da comunidade, polo que estamos moi agradecidos por esta oportunidade. A informática recibe o mesmo amor en EE.
Michael: O noso campo é tan diverso, ten tantas direccións, e afecta á sociedade de tantas formas diferentes que cústame darlle unha resposta definitiva. Pero o caso é que nos últimos 30 anos provocou grandes cambios nos negocios, na industria, na arte e na sociedade en xeral.
Виталий: Comecemos por algo distante. En moitas universidades hai algo así como especialización nunha área determinada. Para a Universidade Carnegie Mellon isto é computación paralela, para o MIT é criptografía, robots e multithreading. Existe tal especialización na Universidade de Rochester?
Michael: Para ser honesto, diría que CMU e MIT están especializados en todas as áreas. O noso departamento sempre prestou a maior atención á intelixencia artificial. A metade das persoas que traballan para nós están implicadas na intelixencia artificial ou na interacción humano-ordenador; esta proporción é maior que noutros departamentos, e sempre o foi. Pero cando estaba na universidade, non tiña ningún curso de IA e nunca traballei neste campo. Así que o meu departamento está especializado nun problema co que non teño nada que ver. O consolo é que o segundo problema máis importante para o noso departamento é a programación paralela e multifíos, é dicir, a miña especialización.
Виталий: Comezaches a traballar en Informática cando xurdía o campo da programación multiproceso. A lista das súas publicacións mostra que os seus primeiros traballos trataron un abano bastante amplo de cuestións: xestión da memoria en sistemas multiproceso, sistemas de ficheiros distribuídos, sistemas operativos. Por que tanta versatilidade? Tentaches atopar o teu lugar na comunidade investigadora?
Michael: Como estudante, participei na Universidade de Wisconsin, onde se desenvolveu un dos primeiros sistemas operativos distribuídos. Alí traballei xunto a Rafael Finkel () e Marvin Solomon (). A miña disertación dedicouse ao desenvolvemento dunha linguaxe para software de sistema para sistemas distribuídos; agora todo o mundo se esqueceu del, e grazas a Deus. Creei a linguaxe de programación Lynx, que tiña a intención de facilitar a creación de servidores para un sistema operativo distribuído pouco acoplado. Dado que naquela época me dedicaba principalmente aos sistemas operativos, asumín que a miña carreira estaría relacionada principalmente con eles. Pero Rochester era unha universidade moi pequena e, por iso, os diferentes grupos interactuaban moi estreitamente entre si. Non había unha ducia de persoas con outros sistemas operativos coa que falar, polo que todos os meus contactos estaban con persoas que traballaban en áreas completamente diferentes. Gustoume moito, ser todoterreno é unha gran vantaxe para min. Se falamos especificamente de estruturas de datos multiproceso e de algoritmos de sincronización, entón comecei a traballar neles por accidente.
Interfaz coherente escalable IEEE, bloqueo MCS.
Виталий: Podes contarme un pouco máis sobre isto?
Michael: Esta é unha historia divertida que non me canso de contar a todos. Ocorreu nunha conferencia en Boston, isto foi a finais dos 80 ou principios dos 90. John Mellor-Crummey (), un graduado da nosa facultade. Coñecíao, pero antes non fixeramos unha investigación conxunta. Mary Vernon () de Wisconsin deron unha charla sobre un sistema multiprocesador que estaban a desenvolver en Wisconsin: . Este Multicube tiña un mecanismo de sincronización a nivel de hardware chamado Q on Sync Bit, e máis tarde foi rebautizado como Q on Lock Bit porque soaba como o queixo Colby, que era un xogo de palabras. Se estás interesado nos mecanismos de multiproceso, probablemente saibas que Colby finalmente se converteu no motor de sincronización do estándar IEEE Scalable Coherent Interface. Este era un mecanismo de bloqueo que creaba punteiros dunha caché a outra a nivel de hardware para que cada titular de bloqueo soubese a quen lle tocaba. Cando John e eu escoitamos isto, mirámonos e dixemos: por que facelo a nivel de hardware? Non se pode conseguir o mesmo usando comparar e intercambiar? Collemos un dos cadernos deitados na aula e garabateamos nel , mentres Mary continuaba co seu informe. Posteriormente, implementámolo, experimentamos, a idea resultou ser exitosa e publicamos o artigo. Daquela, para min, este tema parecía só unha distracción divertida, despois de que pensei volver aos sistemas operativos. Pero entón xurdiu outro problema na mesma liña e, finalmente, a sincronización, o multithreading e as estruturas de datos convertéronse na miña especialidade. Como podes ver, todo isto ocorreu por casualidade.
Виталий: Levo moito tempo familiarizado co bloqueo de MCS, pero ata agora non sabía que era o teu traballo e non entendía que era un acrónimo dos teus apelidos.
Como sobrevivir nun mundo en constante cambio?
Alex: Teño unha pregunta sobre un tema relacionado. Hai 30 ou 40 anos había máis liberdade nas distintas especialidades. Se queres iniciar unha carreira en sistemas multithreading ou distribuídos, benvido, se queres entrar en sistemas operativos, non hai problema. En cada área había moitas preguntas abertas e poucos expertos. Agora xurdiron especializacións estreitas: non só hai expertos en sistemas operativos en xeral, hai especialistas en sistemas individuais. É o mesmo cos sistemas multithreading e distribuídos. Pero o problema é que as nosas vidas non son infinitas; todo o mundo pode dedicar só unhas poucas décadas á investigación. Como sobrevivir neste novo mundo?
Michael: Non somos especiais neste sentido, ocorreu o mesmo noutras zonas. Tiven a sorte de que comecei a traballar en Informática cando o campo estaba na súa "adolescencia". Xa se puxeran algunhas bases, pero aínda estaba todo moi inmaduro. Esta oportunidade non chega a miúdo. A enxeñaría eléctrica existe desde hai moito tempo, a física aínda máis, as matemáticas case desde o principio dos tempos. Pero isto non significa que xa ninguén estea a facer descubrimentos interesantes en matemáticas. Aínda quedan moitos problemas abertos, pero ao mesmo tempo hai que aprender máis. Tes razón ao sinalar que agora hai moitas máis especializacións das que había antes, pero isto só significa que nos atopamos na mesma situación que a maioría das outras áreas da actividade humana.
Alex: Estou interesado no aspecto máis práctico da cuestión aquí. Teño formación en matemáticas, e durante os meus estudos asistín a miúdo a congresos e traballei sobre diversos temas científicos. Descubrín que ninguén da audiencia entendía os meus informes e, do mesmo xeito, os informes doutras persoas eran comprensibles só para eles mesmos. Non é o caso dos temas de alto nivel, pero en canto comezas a afondar en algo, o público xa non pode seguir contigo. Como lides con isto?
Michael: Non sempre ten éxito. Hai pouco preparei un informe no que afondei demasiado nos detalles técnicos. A medida que avanzaba a charla, quedou claro que a maior parte do público non me entendía, polo que tiven que adaptarme á situación sobre a marcha. Non se puideron cambiar as diapositivas, polo que non resultou moi ben, polo que, en xeral, procuro non usar diapositivas. En xeral, o meu consello é que teñas en conta o teu público. Debes saber con quen estás a falar, cal é o seu nivel de coñecemento e o que necesitan escoitar para apreciar o teu traballo.
Виталий: Poderías darnos unha pista de que trataba esta charla?
Michael: Para ser sincero, preferiría non ampliar este tema para deixar as persoas en cuestión no anonimato. A cuestión é que moitas veces afondamos demasiado nas complejidades do problema no que estamos a traballar, polo que se nos fai difícil explicar ao comezo da charla por que o problema é interesante e importante e como se relaciona con cuestións que o público xa o sabe. Segundo as miñas observacións, os alumnos teñen máis dificultades para aprender esta habilidade. E este foi tamén o punto débil do meu recente informe. Un informe debidamente estruturado debe, dende o principio, atopar contacto co público, explicarlle cal é exactamente o problema e como se relaciona con temas xa coñecidos por el. O técnico que sexa esta introdución depende do público. Se é completamente variado, entón o informe pode ser de varias etapas. A introdución debe ser accesible para todos, e ao final a peza pode non poder seguirche, pero as persoas relativamente familiarizadas co teu campo poderán descubrilo.
Os estudantes están a ser máis tontos? Tendencias globais, internacionalización.
Alex: Levas varias décadas observando aos estudantes. Os estudantes son cada vez máis tontos ou intelixentes de década en década ou ano en ano? En Rusia, os profesores quéixanse constantemente de que os estudantes son cada vez máis tontos e realmente non está claro que facer ao respecto.
Michael: Realmente podes escoitar moita negatividade de nós os vellos. Inconscientemente, temos a tendencia a esperar que os estudantes absorban todos os 30 anos de experiencia que xa temos. Se teño unha comprensión máis profunda que en 1985, por que non o teñen os estudantes? Seguramente porque teñen 20 anos, que opinas? Creo que os cambios máis significativos das últimas décadas foron na composición demográfica: agora temos moito máis estudantes internacionais, con excepción dos canadenses. Antes había moitos canadenses porque estamos moi preto da fronteira canadense e os estudantes de alí poden viaxar a casa os fins de semana. Pero agora hai moitas boas universidades en Canadá e os canadenses prefiren estudar aquí; significativamente menos delas chegan aos EUA.
Alex: Cres que esta é unha tendencia local ou global?
Michael: Non lembro exactamente quen, pero alguén dixo que o mundo é plano. O noso campo tornouse moito máis internacional. Antes celebrábanse exclusivamente dentro dos Estados Unidos, despois decidiron celebralos unha vez cada 4 anos noutros países, e agora celébranse en todo o mundo. Estes cambios afectaron aínda máis , xa que sempre foi unha organización máis internacional que ACM. E hai cátedras de programas de China, India, Rusia, Alemaña e moitos outros países, porque agora hai moitas cousas en todas partes.
Alex: Pero, probablemente, hai algúns aspectos negativos desta internacionalización?
Michael: Eu diría que todos os aspectos negativos non están relacionados coa tecnoloxía, senón coa política. Érase unha vez, o principal problema era o feito de que os EE.UU. estaban a roubar as persoas máis intelixentes e talentosas de países de todo o mundo. E agora o principal problema son os xogos políticos entre distintos países arredor dos visados e da inmigración.
Alex: É dicir, barreiras e cousas así. Está claro.
Vladimir: Persoalmente, interésame saber que enfoque adoptas cando ensinas unha nova materia aos estudantes. Hai diferentes opcións: podes tentar en primeiro lugar inspiralos a probar algo novo, ou podes prestar máis atención aos detalles de como funciona unha determinada tecnoloxía. Que prefires?
Traballo eficaz co alumnado
Alex: E como atopar o maldito equilibrio entre o primeiro e o segundo?
Michael: O problema é que as clases non sempre van como me gustaría. Normalmente entrego material de lectura aos alumnos con antelación para que afonden nel, o entendan o mellor posible e formulen preguntas sobre aquelas partes que non puideron comprender. Despois na clase podes centrarte nos momentos máis difíciles e exploralos xuntos. Así é como máis me gusta dar clases. Pero dada a carga que agora recae sobre os estudantes, non sempre son capaz de asegurarme de que se preparen con antelación. Como resultado, tes que dedicar moito máis tempo ao relato xeral do material do que che gustaría. A pesar diso, intento manter as nosas clases interactivas. En caso contrario, é máis doado gravar un vídeo unha vez que os estudantes poidan velo na casa. O punto das clases en directo é a interacción humana. Na clase, prefiro usar xiz e un encerado en lugar de diapositivas, agás en certos casos nos que un diagrama é demasiado complexo para representalo no encerado. Grazas a isto, non teño que atenerme a un ríxido plan de clases. Dado que non hai unha orde estrita na que entrego o material, isto permíteme adaptalo ao público en función das preguntas que reciba. En xeral, procuro que as clases sexan o máis interactivas posible, para que o material que presente dependa das preguntas que se me fagan.
Vladimir: É xenial. Na miña experiencia, é bastante difícil conseguir que os oíntes fagan preguntas. Aínda que pidas con antelación para facer calquera pregunta, por estúpido ou intelixente que sexa, seguen en silencio. Como lides con isto?
Michael: Rirás, pero se permaneces en silencio o tempo suficiente, tarde ou cedo todos se sentirán incómodos e alguén fará unha pregunta. Ou pode facer unha pregunta técnica sinxela cunha resposta si ou non para determinar se a xente entende o que se acaba de dicir. Por exemplo, hai unha carreira de datos no exemplo anterior? Quen pensa así? Quen pensa que non? Quen non entende nada, porque en total só subiron a metade das mans?
Виталий: E se contestaches incorrectamente, é expulsado da clase :)
Michael: Se non respondeches nada, deberías facer unha pregunta. Necesito comprender o que precisa saber exactamente o alumno para responder á pregunta que acabo de facer. Necesito que me axuden a axudalos. Estou preparado para adaptarme a eles para que comprendan o problema. Pero se non sei o que lles pasa na cabeza, non podo facelo. E se non dás tranquilidade aos estudantes durante moito tempo, ás veces ao final fan as preguntas correctas, é dicir, aquelas que me permiten ver que é exactamente o que pasa na cabeza dos estudantes.
Alex: Estas preguntas levan ás veces a ideas que ti mesmo non tiñas pensado antes? Son inesperados? Permítenche mirar un problema cunha nova luz?
Michael: Hai preguntas que abren unha nova forma de presentar o material. Moitas veces hai preguntas que levan a problemas interesantes dos que non pensaba falar. Os estudantes adoitan dicirme que teño a tendencia a saír do tema cando isto ocorre. E, segundo eles, moitas veces esta é a parte máis interesante da lección. Moi poucas veces, só algunhas veces, os estudantes facían preguntas que motivaron unha nova dirección na investigación e convertéronse nun artigo. Isto ocorre con moita máis frecuencia nas conversas cos estudantes que durante as clases, pero ocasionalmente ocorreu durante as clases.
Alex: Entón os alumnos fixéronche preguntas en base ás cales era posible publicar un artigo?
Michael: Si.
Виталий: Cantas veces tes estas conversas cos alumnos? Cando queren aprender máis do que se cubriu durante a lección?
Michael: Cos meus estudantes de posgrao - todo o tempo. Teño uns 5 ou 6 deles, e discutimos algo con eles todo o tempo. E conversas deste tipo con alumnos que simplemente asisten ás miñas clases non son moi habituais. Aínda que me gustaría que isto pasase máis a miúdo. Sospeito que simplemente teñen medo de vir á facultade en horario de oficina. Cada semestre, algúns alumnos conseguen superar esta barreira psicolóxica, e sempre é moi interesante falar con eles despois das clases. É certo que se todos os estudantes fosen tan valentes, simplemente non tería tempo suficiente. Entón, quizais todo funcione como debería.
Виталий: Como consegues atopar tempo para comunicarte cos alumnos? Polo que sei, nos EUA os profesores teñen moito traballo: solicitar subvencións e similares.
Michael: Sinceramente, traballar con estudantes é o aspecto do meu traballo que máis me gusta. Así que teño motivación suficiente para iso. A maior parte do tempo que paso na miña oficina pásano en reunións de todo tipo. Agora é verán, polo que a miña axenda é menos ocupada, pero durante o curso escolar, todos os días de 9 a 17 horas teño todo cargado. Traballos de investigación, revisións, subvencións: para todo isto só hai noites e fins de semana.
Como estar ao día coa preparación de novos cursos e libros.
Alex: Actualmente segues impartindo algún curso que levas impartindo durante moito tempo? Algo así como unha introdución á Informática.
Michael: O primeiro que se me ocorre aquí é un curso de linguaxes de programación.
Alex: Que diferente é a versión actual deste curso da que era hai 10, 20, 30 anos? Quizais o máis interesante aquí non son os detalles dun curso en particular, senón as tendencias xerais.
Michael: O meu curso de linguaxes de programación era algo inusual no momento en que o creei. Comecei a lelo a finais da década de 1980, substituíndo ao meu colega Doug Baldwin (). O tema do curso só estaba tanxencialmente relacionado coa miña especialidade, pero cando el marchou, eu era o mellor candidato para impartir o curso. Non me gustaba ningún dos libros de texto que existían naquel momento, polo que acabei escribindo eu o libro de texto deste curso. (Nota do editor: estamos a falar do libro) Agora úsase en máis de 200 universidades de todo o mundo. O meu enfoque é inusual xa que mestura deliberadamente os problemas do deseño e implementación da linguaxe, e presta moita atención á interacción entre estes aspectos en todos os ámbitos posibles. O enfoque básico permaneceu inalterado, así como moitos conceptos básicos: abstraccións, espazos de nomes, modularidade, tipos. Pero o conxunto de linguaxes coas que se demostran estes conceptos cambiou por completo. Cando se creou o curso, había moitos exemplos en Pascal, pero hoxe moitos dos meus alumnos nin sequera escoitaron falar desta lingua. Pero coñecen Swift, Go, Rust, así que teño que falar das linguas que se usan hoxe. Ademais, agora os estudantes teñen unha boa comprensión das linguaxes de guións, pero cando comecei a impartir este curso, tratábase de linguaxes compiladas. Agora necesitamos moito material sobre Python, Ruby e mesmo Perl, porque este é o código que se escribe nestes días, e hai moitas cousas interesantes que suceden nestas linguaxes, incluso no campo do deseño da linguaxe.
Виталий: Entón a miña seguinte pregunta estará relacionada coa anterior. Como estar ao día nesta zona? Sospeito que actualizar un curso coma este require moito traballo: cómpre comprender novos idiomas, comprender as ideas principais. Como fas isto?
Michael: Non podo presumir de ter sempre éxito ao 100%. Pero a maioría das veces só fago o que fan todos: ler en Internet. Se quero entender Rust, busco en Google, vai á páxina de Mozilla e leo o manual publicado alí. Isto é parte das cousas que suceden no desenvolvemento comercial. Se falamos de ciencia, cómpre seguir os relatorios das principais conferencias.
Vinculación entre empresas e academia
Виталий: Falemos da conexión entre os negocios e a investigación científica. Na túa lista de traballos atopei varios artigos sobre a coherencia da caché. Entendo que os algoritmos de coherencia da caché eran inestables no momento en que se publicaron? Ou non o suficientemente estendido. Que tan comúns eran as túas ideas na práctica?
Michael: Non sei exactamente de que publicacións estás a falar. Traballei bastante cos meus alumnos Bill Bolosky () e Leonidas Kontotanassis () a principios da década de 1990 sobre a xestión da memoria das máquinas Neumann. Nese momento, as empresas aínda non entendían como facer correctamente un sistema multiprocesador: paga a pena crear soporte para acceder á memoria remota a nivel de hardware, paga a pena distribuír a memoria, é posible cargar a caché desde memoria remota, ou é necesario mover páxinas no quirófano? Bill e Leonidas traballaron nesta área e exploraron enfoques sen carga remota da caché. Isto non estaba directamente relacionado coa coherencia da caché, pero aínda era un traballo na xestión da memoria NUMA e, posteriormente, os enfoques modernos para a colocación de páxinas nos sistemas operativos modernos creceron a partir diso. En xeral, Bill e Leonidas fixeron un traballo importante, aínda que non era o máis influente nesta área: había moitas outras persoas traballando no mesmo nese momento. Máis tarde, traballei nun tema relacionado coa coherencia da caché no contexto da memoria transaccional de hardware. O grupo co que traballei neste problema acabou recibindo varias patentes. Hai algunhas ideas bastante interesantes detrás delas, pero non creo que se acaben aplicando na práctica. Dun xeito ou doutro, cústame xulgar a súa rendibilidade.
Alex: A este respecto, unha pregunta máis persoal: que importancia ten para vostede que as súas ideas se poñan en práctica? Ou non pensas niso?
Michael: Encántame facer esta pregunta nas entrevistas con outras persoas, candidatos ou candidatos que queiran unirse á facultade. Non creo que haxa unha resposta correcta a esta pregunta. As persoas que fan cousas interesantes poden ter motivacións moi diferentes. Síntome atraído polos problemas porque persoalmente me parecen interesantes, non polos seus beneficios prácticos. Pero, por outra banda, cando algunha cousa interesante aínda atopa aplicación, gústame moito. Polo tanto, aquí non é doado. Pero ao comezo do meu traballo, aínda non me movía a idea dun uso final no mundo, senón a harmonía da idea e o desexo de explorala e ver o que resulta dela. Se ao final dá resultados prácticos, xenial.
Alex: Debido á súa educación e experiencia, é mellor que a maioría para xulgar o valor das ideas doutras persoas. Podes comparalos e determinar cal funciona mellor con cal. Seguro que tes unha opinión sobre cousas que actualmente están a ser utilizadas na práctica por grandes fabricantes como Intel. Desde o teu punto de vista, ¿que tan correcto é o rumbo que están a seguir estas empresas?
Michael: A práctica sempre xira en torno ao que pode ter éxito comercialmente, é dicir, crear beneficios, e é mellor que lle preguntes a outra persoa sobre iso. O meu traballo dá lugar na súa maioría a publicacións, e no ámbito dos sistemas operativos avalíanse en función de indicadores de rendemento: velocidade, consumo enerxético, tamaño do código. Pero sempre me pareceu que estes resultados empíricos engádense aos artigos só para que poidan ser publicados, e os motivos reais da xente para traballar son estéticos. Os investigadores avalían as solucións desde unha perspectiva artística, preocúpanse polo elegante que son as ideas e tratan de crear algo mellor que os enfoques existentes. Os investigadores están dirixidos por motivos persoais, subxectivos e estéticos. Pero non podes escribir sobre isto no propio artigo; estas cousas non son argumentos para o comité do programa. Afortunadamente, as solucións elegantes adoitan ser tamén rápidas e baratas. Unha ducia dos meus compañeiros e eu falamos deste tema hai uns 15 anos e acabamos escribindo un artigo sobre el. Creo que aínda podes atopalo agora, chámase ou algo así, ten máis dunha ducia de autores. Este é o único artigo no que son o autor xunto con eu , así que se buscas o seu nome na miña lista de publicacións, atoparás o que necesitas. Fala de avaliar a investigación de sistemas e da importancia da elegancia.
Alex: Entón, hai unha diferenza entre o estándar do que se considera bo na ciencia e nos negocios. A ciencia avalía o rendemento, o consumo de enerxía, o TDP, a facilidade de implementación e moito máis. Tes a oportunidade de realizar este tipo de investigacións na universidade? Tes un laboratorio con diferentes máquinas e diferentes arquitecturas no que poidas realizar experimentos?
Michael: Si, o noso departamento ten moitas máquinas interesantes. A maioría das veces son pequenos, temos un pequeno clúster e moitos sistemas multiprocesador con diferentes aceleradores. Ademais, o campus ten un enorme centro de computación que atende a científicos de varias ducias de disciplinas diferentes. Ten uns mil nodos e vinte mil núcleos, todos en Linux. Se é necesario, sempre podes mercar algún AWS. Polo tanto, non temos restricións significativas co hardware.
Alex: Como era hai trinta anos? Houbo problemas entón?
Michael: Daquela era un pouco diferente. A mediados e finais dos anos 1980, considerábase que a ciencia carecía de recursos informáticos. Para remediar esta situación, a National Science Foundation ) creou un programa de investigación experimental coordinada (Coordinated Experimental Research, CER). A misión do programa era proporcionar infraestrutura de computación para os departamentos de Informática, e conseguiu cambios significativos. Co diñeiro que ela proporcionou, na Universidade de Rochester compramos unha bolboreta BBN de 1984 nós en 128, isto foi un ano antes de que eu chegase alí. Daquela era o sistema multiprocesador máis grande do mundo con memoria compartida. Tiña 128 procesadores, cada un nunha placa base separada, e ocupaba catro racks. Cada procesador tiña un megabyte de memoria, 128 megabytes de RAM era unha cantidade inimaxinable naquel momento. Nesta máquina implementamos o bloqueo MCS por primeira vez.
Alex: Entón, se o entendo correctamente, entón o problema co hardware resolveuse neste momento?
Michael: En xeral, si. Hai algunhas advertencias: primeiro, se estás facendo arquitectura de ordenadores a nivel de chip, é difícil facelo nun ambiente académico porque hai ferramentas moito mellores para facelo nos negocios. Se necesitas algo de menos de 10 nanómetros, terás que encargalo a outra persoa. Neste ámbito é moito máis doado ser investigador en Intel. Se estás traballando en comunicacións ópticas en chips ou en memoria de estado sólido, atoparás nos negocios tecnoloxías que aínda non están na ciencia, polo que tes que crear alianzas. Por exemplo, Stephen Swanson () creada para as novas tecnoloxías da memoria. Este formulario non sempre funciona, pero nalgúns casos pode ter bastante éxito. Ademais, na ciencia é máis difícil o desenvolvemento dos sistemas informáticos máis potentes. Os maiores proxectos de supercomputadoras actualmente en EE. UU., Xapón e China están enfocados aos negocios.
Aplicación práctica de ideas. MCS, MS, CLH, JSR 166, traballando con Doug Lee e moito máis.
Виталий: Xa falaches de como comezaches a traballar nos algoritmos de sincronización. Tes dous artigos moi famosos sobre и , que en certo sentido foron implementados en Java. (Nota do editor: pódense ver todas as publicacións ). Alí implementouse este bloqueo con algúns cambios e resultou , e a cola implementouse segundo o previsto. Pero pasaron moitos anos entre a publicación dos teus artigos e a súa aplicación práctica.
Alex: Parece uns 10 anos no caso da cola.
Michael: Antes de aparecer estas funcións na biblioteca estándar de Java?
Виталий: Si. Que fixeches para que isto acontecese? Ou non fixeron nada?
Michael: Podo contarche como MS Queue entrou en Java 5. Uns anos antes de que saíra, traballei co grupo de Mark Moyers en Sun Microsystems no seu laboratorio preto de Boston. Organizou un obradoiro para persoas que coñecía que estaban traballando en problemas interesantes en multithreading porque quería atopar temas que puidese vender á súa empresa. Aí foi onde coñecín a Doug Lea. Doug e eu e outras 25 persoas de Sun estivemos xuntos discutindo a presentación de Doug , que máis tarde se converteu en java.util.concurrent. Durante o camiño, Doug dixo que lle gustaría usar a cola MS, pero para iso necesitaba un contador para o número de elementos da cola para a interface. É dicir, debería terse feito por un método separado, atómico, preciso e rápido. Suxerín simplemente engadir números de serie aos nodos, collendo o número do primeiro e do último e restando un do outro. Doug rascouse a cabeza, dixo "por que non" e acabou facendo exactamente iso. Discutimos sobre a implementación deste enfoque na biblioteca, pero Doug fixo a maior parte do traballo el mesmo. Como resultado, logrou establecer un excelente soporte multithreading en Java.
Alex: Entón, se entendo ben, o método .size() debería ter formado parte da interface estándar da cola e debería ter unha complexidade algorítmica de O(1)?
Michael: Si, e ademais disto, é necesario un contador separado.
Alex: Porque se chama ao método .size() en Java, espérase que o resultado estea dispoñible inmediatamente e non baseado no tamaño real da colección. Xa vexo, grazas.
Michael: Uns anos despois estiven traballando en estruturas de datos duais co meu alumno Bill Scherer; de feito, isto é do que vou falar . Doug veu a nós e dixo que podía usalos no Java Executor Framework. Xunto con Bill, crearon dúas implementacións, as chamadas filas xustas e inxustas. Aconseilleilles neste proxecto, aínda que non participei na escritura do código real. Como resultado, a velocidade dos executores aumentou significativamente.
Vladimir: Encontrou implementacións incorrectas dos seus algoritmos ou solicitudes para engadir novas funcións? En xeral, a práctica debería coincidir coa teoría, pero moitas veces difiren. Supoña que escribiu un algoritmo, e en papel funciona, pero as persoas que están implicadas na implementación comezaron a pedirche máis funcións ou algún tipo de axuste do algoritmo. Tiveches algunha vez tales situacións?
Michael: O único exemplo no que alguén me veu e preguntou "como implementalo" foi a pregunta de Doug, da que xa falei. Pero houbo algúns casos nos que se fixeron cambios interesantes para atender ás necesidades prácticas. Por exemplo, o equipo de K42 de IBM converteu o bloqueo MCS e converteuno nunha interface estándar polo que non había necesidade de pasar o nodo da cola de ida e volta ás rutinas de adquisición e liberación. Grazas a esta interface estándar, unha idea que era fermosa en teoría comezou a funcionar na práctica. Sorprende que nunca publicaran un artigo ao respecto, e aínda que recibiron unha patente, logo abandonaron. A idea foi marabillosa, e intento falar dela sempre que sexa posible.
Houbo outros casos nos que a xente fixo melloras nos algoritmos que publiquei. Por exemplo, a cola MS ten un mecanismo de instalación de dous pasos, o que significaba que había dous CAS na ruta crítica da cola. Nos coches máis antigos, os CAS eran bastante caros. Intel e outros fabricantes optimizáronos bastante ben recentemente, pero noutrora eran instrucións de 30 ciclos, polo que non era desexable ter máis dunha no camiño crítico. Como resultado, desenvolveuse unha cola diferente que era similar á cola MS, pero que tiña só unha operación atómica no camiño crítico. Isto conseguiuse debido ao feito de que durante un certo período de tempo a operación podía levar tempo O(n) en lugar de O(1). Era improbable, pero posible. Isto ocorreu debido a que en determinados momentos o algoritmo percorreu a cola desde o principio ata a posición actual nesta cola. En xeral, o algoritmo resultou ser moi exitoso. Polo que sei, non é moi utilizado, en parte porque as operacións atómicas requiren significativamente menos recursos que antes. Pero a idea foi xenial. Tamén me gusta moito o traballo de Dave Dice de Oracle. Todo o que fai é moi práctico e utiliza o ferro de forma moi intelixente. Tivo unha man en gran parte dos algoritmos de sincronización conscientes de NUMA e estruturas de datos multiproceso.
Vladimir: Cando escribes algoritmos ou ensinas aos estudantes, o resultado do teu traballo non é inmediatamente visible. A comunidade necesita un tempo para familiarizarse con, por exemplo, un novo artigo. O novo algoritmo non atopa aplicación inmediatamente.
Michael: Non está moi claro se o artigo será significativo ou non. Creo que sería interesante facer un estudo de traballos premiados en congresos. É dicir, mira os artigos que a xente das comisións do programa nalgún momento consideraba os mellores. Debes tentar calcular polo número de ligazóns e o impacto nos negocios a influencia que tiveron estes artigos en 10, 20 ou 25 anos. Dubido que haxa unha forte correlación entre ambos. Non será cero, pero o máis probable é que sexa moito máis débil do que nos gustaría. Moitas ideas permanecen sen reclamar durante moito tempo antes de que se xeneralicen. Por exemplo, tomemos a memoria transaccional. Pasaron máis de 10 anos desde que se publicou o artigo orixinal ata que a xente comezou a construír máquinas con el. E antes da aparición desta memoria en produtos comerciais - e todos os 20. Durante moito tempo ninguén prestou atención ao artigo, e entón o número de ligazóns a el aumentou moito. Sería difícil prever isto con antelación. Por outra banda, ás veces as ideas atopan implementación inmediatamente. Hai uns anos, escribín un artigo con Joe Izraelevitz para DISC que propoñía unha nova definición formal de validez para estruturas de datos persistentes que se podían utilizar despois de que o ordenador que as executaba fallase. O artigo gustoume dende o principio, pero resultou ser moito máis popular do que esperaba. Foi usado por varios grupos diferentes e, finalmente, converteuse na definición estándar de estruturas de persistencia. O que, por suposto, é bo.
Vladimir: Hai algunha técnica que utilices para a avaliación? Tentas incluso avaliar os teus artigos e os teus estudantes? En canto a se a persoa que ensinaches vai na dirección correcta.
Michael: Como todo o mundo, presto máis atención ao que estou a facer neste momento. De novo, como todo o mundo, de vez en cando comprobo Google Scholar para ver se se citan os meus traballos anteriores, pero iso é máis por curiosidade. Sobre todo estou absorto no que os meus estudantes están facendo agora. Á hora de valorar o traballo actual, parte son consideracións estéticas, o que é elegante e o que non. E a nivel cotián, as preguntas abertas xogan un papel importante. Por exemplo, un alumno vén a min cunha gráfica dalgúns resultados, e estamos tentando entender de onde veu algún comportamento estraño da gráfica. En xeral, no noso traballo estamos constantemente tentando comprender cousas que aínda non entendemos.
Memoria transaccional
Виталий: Quizais poidamos falar un pouco da memoria transaccional?
Michael: Creo que paga a pena dicir polo menos un pouco porque me esforzo moito. Este é un tema sobre o que teño máis publicacións que calquera outro. Pero ao mesmo tempo, curiosamente, sempre fun moi escéptico sobre a memoria transaccional. Na miña opinión, (M. Herlihy, J. E. B. Moss) publicouse antes do seu tempo. A principios da década de 1990, suxeriron que a memoria transaccional podería axudar aos programadores talentosos a traballar en estruturas de datos multiproceso, de xeito que estas estruturas poderían ser utilizadas como bibliotecas polos programadores comúns. É dicir, sería unha axuda para Doug Lee facendo o seu JSR 166. Pero a memoria transaccional non estaba destinada a facilitar a programación multiproceso. Pero así foi exactamente como comezou a percibirse a principios dos anos 2000, cando se estendeu. Anunciuse como unha forma de resolver o problema da programación paralela. Este enfoque sempre me pareceu desesperado. A memoria transaccional só podería facilitar a escritura de estruturas de datos paralelas. Isto, paréceme, é o que conseguiu.
Sobre a dificultade de escribir código multiproceso
Alex: Moi interesante. Parece que hai unha certa barreira entre os programadores habituais e os que poden escribir código multiproceso. O ano pasado, falei varias veces con persoas que estaban a implementar algún marco algorítmico. Por exemplo, con Martin Thomson, así como con programadores que traballan en bibliotecas multiproceso. (Nota do editor: Martin Thompson é un programador moi famoso, escribiu и . E tamén ten na nosa conferencia Joker 2015, gravación de vídeo . El é o mesmo esta conferencia tamén dispoñible). O principal reto, din, é facer que os algoritmos sexan rápidos e fáciles de usar. É dicir, intentan superar esta barreira e atraer a maior cantidade de xente posible a esta zona. Que opinas diso?
Michael: Este é o principal problema do multithreading: como conseguir un alto rendemento sen aumentar a complexidade do sistema.
Alex: Porque cando intentan evitar a complexidade, o algoritmo faise menos universal.
Michael: A clave aquí son as abstraccións deseñadas correctamente. Paréceme que isto é xeralmente o principal para os sistemas informáticos como campo. A Butler Lampson gústalle usar este termo e chámanos "comerciantes de abstraccións". As tecnoloxías sinxelas non existen hoxe en día. Os procesadores que usamos teñen 10 millóns de transistores; a simplicidade está fóra de cuestión. Ao mesmo tempo, o ISA é moito máis sinxelo que o procesador, xa que traballamos durante moito tempo para proporcionarlle un alto rendemento e unha interface relativamente sinxela. Pero tampouco todo está ben con ela. O mesmo problema é cos aceleradores que agora están a aparecer no mercado. Xorden preguntas: como facer a interface correcta para a GPU, un mecanismo de cifrado, compresión, un mecanismo de transcodificación, un mecanismo de álxebra lineal ou mesmo un FPGA máis flexible. Como crear unha interface que faga que a ferramenta sexa fácil de usar e que oculte a complexidade? Non se librará del, senón que o ocultará a un programador sinxelo.
Alex: Segundo o entendo, aínda temos unha barreira para comprender as abstraccións. Tomemos o modelo da memoria; na nosa etapa de desenvolvemento da ciencia e da tecnoloxía, esta é unha das principais abstraccións. Grazas a el, todos os programadores están divididos en dous grupos: a maior parte son os que non o entenden, e a menor parte son os que entenden, ou pensan que entenden.
Michael: Esa é unha boa pregunta: algún de nós entende realmente o modelo de memoria?
Виталий: Especialmente en C++.
Michael: Fale con Hans Boehm algunha vez. É unha das persoas máis intelixentes que coñezo, un experto destacado en modelos de memoria. Enseguida diráche que hai moitas cousas que non entende. Pero se volvemos á cuestión das abstraccións, entón, na miña opinión, expresouse a idea máis importante no campo dos modelos de memoria nos últimos 30 anos. . (Nota do editor: está dispoñible unha lista completa de publicacións ).
Alex: A miña pregunta é: esta barreira vén da propia natureza do concepto?
Michael: Non. Sarita chegou á conclusión de que co enfoque correcto, pode ocultar con éxito toda a complexidade, obter un alto rendemento e darlle ao programador unha API sinxela. E se segues esta API, podes conseguir unha coherencia consistente. Creo que este é o modelo correcto. Escribe código sen carreiras de datos e obtén consistencia secuencial. Por suposto, para reducir a probabilidade de carreiras, necesítanse ferramentas especiais, pero esa é outra cuestión.
Vladimir: Houbo momentos na túa carreira en que un problema que parecía solucionado se converteu de súpeto nunha catástrofe, ou resultou que este problema era irresoluble? Por exemplo, en teoría pode factorizar calquera número ou determinar se algún número é primo. Pero na práctica isto pode ser difícil de facer; co hardware actual é difícil factorizar os números. Chegouche algo parecido?
Michael: Non lembro nada diso inmediatamente. Houbo momentos nos que me parecía que non quedaba nada que facer nunha zona determinada, pero entón alí pasou algo novo e interesante. Por exemplo, pensei que a área de cola ilimitada xa alcanzara a madurez. Despois de varias melloras na cola MNS, xa non pasou moito. E entón Morrison (Adam Morrison) e Afek (Yehuda Afek) inventaron . Quedou claro que era posible unha cola multiproceso ilimitada, onde a maioría das veces só había unha instrución de recuperación e incremento no camiño crítico. E isto permitiu acadar unha orde de magnitude mellor rendemento. Non é que non saibamos que buscar e incrementar é algo moi útil. Eric Freudenthal escribiu sobre isto no seu traballo sobre a Ultracomputadora con Allan Gottlieb a finais dos anos 1980, pero tratábase de colas limitadas. Morrison e Afek puideron usar a función de buscar e incrementar nunha cola sen límites.
Novas arquitecturas. Está preto a vitoria da memoria transaccional?
Vladimir: Buscas novas solucións arquitectónicas que poidan ser útiles para os algoritmos?
Michael: Por suposto, hai moitas cousas que me gustaría ver implementadas.
Vladimir: De que tipo, por exemplo?
Michael: En primeiro lugar, algunhas extensións sinxelas para a nosa memoria transaccional a nivel de hardware nos procesadores Intel e IBM. En particular, gustaríame que a carga e a tenda non transacionais que acaban de ocorrer estean dispoñibles de inmediato dentro das transaccións. Inmediatamente levan a bucles na secuencia sucede antes, polo que poden ser difíciles. Pero se mantés capas de abstracción, hai moitas cousas moi interesantes que podes facer fóra da transacción mentres está a suceder. Non sei o difícil que sería de implementar, pero sería moi útil.
Outra cousa útil é cargar a caché desde a memoria remota. Creo que tarde ou cedo se fará. Esta tecnoloxía permitirá a creación de sistemas con memoria desagregada. Sería posible manter, por exemplo, 100 terabytes de memoria non volátil nun rack, e o propio sistema operativo decidiría dinámicamente que seccións desa memoria deberían corresponder ao espazo de enderezo físico dos procesadores. Isto sería moi útil para a computación na nube, xa que permitiría proporcionar grandes cantidades de memoria ás tarefas que o precisen. Creo que alguén o fará.
Виталий: Para rematar de falar da memoria transaccional, teño unha pregunta máis sobre este tema. A memoria transaccional substituirá finalmente as estruturas estándar de datos multiproceso?
Michael: Non. As transaccións son un mecanismo especulativo. A nivel de programación son bloqueos atómicos, pero dentro son especulacións. Tal previsión funciona se a maioría das suposicións son correctas. Polo tanto, a memoria transaccional funciona ben cando os fíos apenas interactúan entre si, e só tes que asegurarte de que non haxa interaccións. Pero se unha mensaxe comeza entre fíos de conversa, as transaccións non serven de nada. Déixame explicar, estamos a falar do caso en que as transaccións se envolven en torno a toda a operación atómica. Aínda se poden usar con éxito como compoñentes para estruturas de datos multiproceso. Por exemplo, se necesitas un CAS de tres palabras e necesitas multithread tres pequenas cousas no medio dun algoritmo verdadeiramente multithread que funciona con vinte threads ao mesmo tempo. En xeral, as transaccións poden ser útiles, pero non eliminarán a necesidade de deseñar correctamente estruturas de datos multiproceso.
Memoria non volátil, Optane DIMM, dispositivos ultra-rápidos.
Виталий: O último do que me gustaría falar é o tema da túa investigación actual: a memoria non volátil. Que podemos esperar neste ámbito nun futuro próximo? Quizais coñeces algunha implementación efectiva que xa exista?
Michael: Non son un experto en hardware, só sei o que lin nas noticias e o que me din os meus compañeiros. Todo o mundo xa escoitou que Intel vende , que teñen aproximadamente 3 veces a latencia de lectura e 10 veces a latencia de escritura que a RAM dinámica. En breve estarán dispoñibles en versións de gran volume. É curioso pensar que poderías ter un portátil con varios terabytes de RAM direccionable por bytes. É probable que dentro de 10 anos decidamos usar esta nova tecnoloxía, xa que usamos DRAM, só aumenta o volume. Pero grazas á independencia enerxética ábrense oportunidades completamente novas. Podemos cambiar fundamentalmente a pila de almacenamento para que non haxa separación entre a memoria de traballo direccionable por bytes e a memoria persistente estruturada en bloques. Así, non necesitaremos serializar todo o que hai que transferir dun programa a outro en ficheiros estruturados en bloque. Diso podemos derivar moitos principios importantes que afectan aos sistemas operativos, aos ambientes de execución e aos almacéns de datos distribuídos. Esta área é moi interesante para traballar. Persoalmente, é difícil para min prever a que vai levar todo isto, pero os problemas aquí son moi divertidos. Aquí pode haber cambios revolucionarios, e seguen moi naturalmente o traballo sobre multithreading, xa que a recuperación de fallos é un proceso de "multithreading" xunto ao funcionamento normal do sistema.
O segundo tema principal no que estou a traballar actualmente é a xestión de dispositivos ultrarrápidos e o acceso seguro aos dispositivos desde o espazo de usuario con control de políticas sistémicas. Nos últimos anos, houbo unha tendencia a mover o acceso ao dispositivo ao espazo de usuario. Isto faise porque a pila do núcleo TCP-IP non pode funcionar enriba dunha interface de rede que necesita un novo paquete cada 5 microsegundos; simplemente non vai seguir. Polo tanto, os fabricantes ofrecen acceso directo aos dispositivos. Pero isto significa que o sistema operativo perde o control do proceso e non pode proporcionar o acceso adecuado ao dispositivo para as aplicacións da competencia. O noso equipo de investigación cre que se pode evitar esta deficiencia. Teremos un artigo sobre isto en USENIX ATC este mes. Está relacionado co traballo sobre a persistencia, xa que a memoria persistente direccionable por bytes de longa duración é, en esencia, un dispositivo con E/S ultrarrápida ao que hai que acceder no espazo de usuario. Esta investigación fai posibles novos enfoques para os micronúcleos, exokernels e outros intentos tradicionais de mover con seguridade a funcionalidade do núcleo do sistema operativo ao espazo de usuario.
Vladimir: A memoria direccionable por bytes é xenial, pero hai unha limitación física: a velocidade da luz. Isto significa que inevitablemente haberá un atraso ao interactuar co dispositivo.
Michael: Absolutamente seguro.
Vladimir: Haberá capacidade suficiente para facer fronte ás novas cargas?
Michael: Esta é unha excelente pregunta, pero será difícil para min responder. A idea de procesar na memoria existe desde hai bastante tempo, é moi interesante, pero tamén moi complexa. Non traballei neste ámbito, pero sería xenial que alí se fixeran algúns descubrimentos. Temo que non teño máis nada que engadir.
Vladimir: Hai un problema máis. Será imposible encaixar na CPU cantidades novas e significativamente maiores de RAM. Polo tanto, debido ás limitacións físicas, esta memoria RAM debe estar illada.
Michael: Todo depende do número de defectos na produción de circuítos integrados. Se fose posible crear obleas de semicondutores totalmente sen defectos, entón sería posible facer un microcircuíto completo. Pero agora non sabemos como facer microcircuítos máis grandes que os selos de correos.
Vladimir: Pero aínda estamos a falar de tamaños enormes, duns centímetros. Isto ten un impacto inevitable na latencia.
Michael: Si. Non hai nada que poidas facer coa velocidade da luz.
Vladimir: Desafortunadamente.
A próxima gran tendencia. Estruturas de datos duais. Hidra.
Виталий: Polo que entendo, captas as novas tendencias moi rapidamente. Foi un dos primeiros en traballar na memoria transaccional e un dos primeiros en traballar na memoria non volátil. Cal cres que será a próxima gran tendencia? Ou quizais sexa un segredo?
Michael: Para ser sincero, non o sei. Espero poder notar cando xurda algo novo. Non tiven a sorte de inventar ningún campo novo pola miña conta, pero tiven un pouco de sorte e puiden comezar a traballar bastante cedo en campos novos creados por outros. Espero poder facelo no futuro.
Alex: A última pregunta desta entrevista será sobre a túa actuación en Hydra e as túas actividades na escola. Se entendo ben, o informe da escola versará sobre algoritmos sen bloqueo, e na conferencia sobre estruturas de datos dobres. Poderías dicir algunhas palabras sobre estes informes?
Michael: En parte, xa tocamos estes temas contigo nesta entrevista. Trátase do traballo que fixen co meu alumno Bill Scherer. Escribiu unha tese sobre ela, e Doug Lee tamén contribuíu a ela, e finalmente pasou a formar parte das colas síncronas multiproceso da biblioteca Java. Supoñamos que a estrutura de datos se li e escribe sen bloquear, é dicir, que cada operación ten un número limitado de instrucións no camiño crítico. Se tentas eliminar datos dun contedor baleiro, ou tentas eliminar certos datos que non estean neste contedor, infórmache inmediatamente de que non se pode facer. Pero este comportamento pode non ser aceptable se o fío realmente necesita estes datos. Entón o primeiro que se me ocorre é crear un bucle que preguntará constantemente se apareceron os datos necesarios. Pero despois hai interferencia para todos os demais. Ademais, con este enfoque, podes esperar 10 minutos, e despois chegará outro fío e recibirá accidentalmente os datos necesarios primeiro. As estruturas de datos dobres aínda non teñen bloqueos, pero permiten que os fíos esperen correctamente. O termo "dobre" significa que a estrutura contén datos ou solicitudes de datos, chamémoslles anti-datos. Polo tanto, se tentas recuperar algo dun contedor baleiro, colocarase unha solicitude no contedor. Agora o fío pode esperar unha solicitude sen molestar a ninguén. Ademais, a estrutura de datos asigna prioridades ás solicitudes para que, cando se reciban, as transmita á persoa adecuada. O resultado é un mecanismo sen bloqueo que aínda ten unha especificación formal e un bo rendemento na práctica.
Alex: Cales son as súas expectativas desta estrutura de datos? Mellorará o rendemento en todos os casos habituais ou é máis adecuado para determinadas situacións?
Michael: É útil se, en primeiro lugar, necesitas un contedor sen bloqueo e, en segundo lugar, cómpre esperar nunha situación na que necesites recuperar datos do contedor que non estea nel. Segundo o meu coñecemento, o noso marco ofrece un comportamento óptimo cando se cumpren estas dúas condicións. Polo tanto, nestes casos recomendo usalo. A principal vantaxe das estruturas de datos sen bloqueo é que evitan problemas de rendemento. E esperar é moi importante en moitos algoritmos se os datos se transfiren dun fío a outro.
Виталий: Permíteme aclarar: falarás do mesmo tanto na escola como no congreso?
Michael: Na escola en xeral, sobre estruturas de datos multiproceso, cos principios básicos descritos ao comezo da lección. Supoño que o público sabe o que son os fíos e está familiarizado cos bloqueos. Con base neste coñecemento básico, falarei de estruturas de datos sen bloqueo. Darei unha visión xeral dos problemas máis importantes nesta área, tocando temas como a xestión da memoria. Non creo que haxa nada máis complicado que a cola de MS.
Alex: Estás a planear ensinar sobre estruturas de datos duais ao final da túa clase na escola?
Michael: Mencionareinos, pero non lles dedicarei moito tempo. A eles estará dedicado o informe Hydra. Abarcará o proxecto que finalmente chegou a Java, ademais de traballar con Joe Israelevich para crear unha variante dual da cola LCRQ e crear un deseño case universal para estruturas de datos duais.
Alex: Entón, a charla na escola pódese recomendar para principiantes, e a charla sobre estruturas de datos dobres sobre Hydra, para persoas que xa teñen algunha experiencia?
Michael: Corríxeme se me equivoco, pero a audiencia de Hydra será bastante diversa, incluíndo moitos expertos en Java e, en xeral, persoas que non estean especificamente implicadas na programación multiproceso.
Виталий: Si, é verdade.
Alex: Polo menos así o esperamos.
Michael: Neste caso, atopareime ante o mesmo problema co que comezamos esta entrevista: como facer unha reportaxe á vez suficientemente rica en detalles técnicos e accesible para todos os oíntes.
Виталий: Darás un informe do mesmo xeito que das conferencias? É dicir, falar co público e adaptarse á situación?
Michael: Temo que non funcione así, porque o informe terá diapositivas. As diapositivas son importantes cando os oíntes falan inicialmente diferentes idiomas. Moitas persoas terán dificultades para entenderme en inglés, especialmente se falo demasiado rápido. Escollín estes temas porque pediume que falara sobre estruturas de datos sen bloqueo na Escola SPTDC; e entón necesitaba un informe para unha conferencia de grupos de usuarios de Java e quería escoller algo que fose de interese específico para os programadores de Java. O xeito máis doado era falar desas cousas na biblioteca de Java que tiña unha man dun xeito ou doutro.
Alex: Supoñemos que o público de Hydra xa sabe algo sobre a programación sen bloqueo e quizais teña algunha experiencia nesta área. Pero isto é só unha suposición; a situación quedará máis clara na propia conferencia. De todos os xeitos, grazas polo teu tempo. Seguro que a entrevista será moi interesante para os nosos lectores. Moitas grazas!
Виталий: Grazas.
Michael: Estarei encantado de coñecerte en San Petersburgo.
Alex: Nós tamén, temos unha cidade fermosa. Algunha vez estivo aquí?
Michael: Non, nunca estiven en Rusia. Pero San Petersburgo sempre estivo na lista de lugares nos que aínda non fun, pero onde teño moitas ganas de ir, polo que me alegrou moito da invitación.
Alex: Por certo, teremos un programa de excursións para relatores. Moitas grazas pola entrevista, e que teñades un bo día!
Podes continuar a conversa con Michael na conferencia Hydra 2019, que se celebrará do 11 ao 12 de xullo de 2019 en San Petersburgo. Virá cun informe . As entradas pódense mercar .
Fonte: www.habr.com