- como profesor de informática na Universidade de Rochester e exerceu como decano durante cinco anos na súa alma mater, a Universidade de Wisconsin-Madison. Realiza investigacións en programación paralela e distribuída e deseño de linguaxes, e imparte estas materias aos estudantes.
O mundo coñece a Michael polo libro de texto , e traballo recibiu o Premio Dijkstra como un dos máis recoñecidos no campo da computación distribuída. Tamén o coñeces como o autor dese mesmo algoritmo .
Xunto con Doug Lee, desenvolveu os algoritmos non bloqueantes e as colas síncronas que alimentan as bibliotecas de Java. JavaSE 6 mellorou o rendemento en 10 veces. ThreadPoolExecutor.
Contido:
- Inicios da carreira, Universidade de Rochester. Proxecto Charlotte, lingua Lynx;
- Interface coherente escalable IEEE, bloqueo MCS;
- Supervivencia nun mundo en constante cambio;
- Están os estudantes a volverse máis parvos? Tendencias globais, internacionalización;
- Traballo eficaz cos estudantes;
- Como manterse ao día das últimas novidades na preparación de novos cursos e libros;
- Conexión entre as empresas e o mundo académico;
- Poñendo ideas en práctica. MCS, MS, CLH, JSR 166, traballando con Doug Lee e moito máis;
- Memoria transaccional;
- Novas arquitecturas. A memoria transaccional está a piques de vitoria;
- Memoria non volátil, Optane DIMM, dispositivos ultrarrápidos;
- A seguinte gran tendencia. Estruturas de datos duais. Hydra.
As entrevistas son realizadas por:
Vitali Aksenov — é actualmente investigador posdoutoral no IST Austria e membro do Departamento de Ciencias da Computación da Universidade ITMO. A súa investigación céntrase na teoría e práctica das estruturas de datos simultáneas. Antes de unirse ao IST, recibiu o seu doutoramento na Universidade París Diderot e na Universidade ITMO baixo a supervisión do profesor Petr 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.
Inicios da carreira, Universidade de Rochester. Proxecto Charlotte, lingua Lynx.
AlexPrimeiro de todo, quería dicirche que en Rusia todos somos moi afeccionados á informática, á ciencia de datos e aos algoritmos. É case indecente. Todos lemos Polo tanto, a próxima conferencia, a escola e esta propia entrevista deberían ser moi populares. Recibimos numerosas preguntas para esta entrevista de estudantes, programadores e membros da comunidade, polo que estamos moi agradecidos por esta oportunidade. É a informática tan popular nos Estados Unidos?
MichaelO noso campo é tan diverso, ten tantas ramas e impacta na sociedade de tantos xeitos, que me resulta difícil darche unha resposta definitiva. Pero o certo é que impulsou enormes cambios nos negocios, na industria, nas artes e na sociedade no seu conxunto nos últimos 30 anos.
ВиталийComecemos con algo máis remoto. Moitas universidades teñen algún tipo de especialización nunha área concreta. Para Carnegie Mellon, é a computación paralela; para o MIT, é a criptografía, a robótica e a multiprocesamento. A Universidade de Rochester ten unha especialización similar?
MichaelSinceramente, eu diría que a CMU e o MIT especialízanse en todo. O noso departamento sempre se centrou na intelixencia artificial. A metade do noso persoal traballa en IA ou interacción persoa-computadora, unha proporción maior que noutros departamentos, e sempre foi así. Pero cando estaba na CMU, non tiña ningún curso de IA e nunca traballei nela. Entón, o meu departamento especialízase nun problema co que non teño ningunha conexión. A boa noticia é que o segundo problema máis importante do noso departamento é a programación simultánea e multiproceso, que é a miña área de especialización.
ВиталийComezaches a traballar en informática cando o campo da programación multiproceso estaba a xurdir. A xulgar pola túa lista de publicacións, os teus primeiros traballos abarcaron unha gama bastante ampla de temas: xestión de memoria en sistemas multiproceso, sistemas de ficheiros distribuídos e sistemas operativos. Por que tanta versatilidade? Estabas a tentar atopar o teu lugar na comunidade investigadora?
MichaelComo estudante, participei en na Universidade de Wisconsin, onde se desenvolveu un dos primeiros sistemas operativos distribuídos. Alí traballei con Raphael Finkel () e Marvin Solomon (). A miña disertación trataba sobre o desenvolvemento dunha linguaxe de software de sistema para sistemas distribuídos; grazas a Deus, agora está case esquecida. Creei a linguaxe de programación Lynx, que pretendía simplificar a creación de servidores para un sistema operativo distribuído pouco acoplado. Dado que nese momento traballaba principalmente en sistemas operativos, supuxen que a miña carreira tamén se centraría neles. Pero a Universidade de Rochester era moi pequena e, por iso, os diferentes grupos alí interactuaban moi estreitamente entre si. Non había unha ducia doutros especialistas en sistemas operativos cos que puidese interactuar, polo que todos os meus contactos eran con persoas que traballaban en campos completamente diferentes. Gocei moito disto; ser xeneralista era unha gran vantaxe para min. En canto ás estruturas de datos multifío e aos algoritmos de sincronización en concreto, comecei a traballar neles por accidente.
Interface coherente escalable IEEE, bloqueo MCS.
Виталий: Podes explicar un pouco máis sobre isto?
MichaelEsta é unha historia divertida que nunca me canso de contarlle a todo o mundo. Sucedeu nunha conferencia. en Boston - foi a finais dos anos 80 ou principios dos 90. John Mellor-Crummie estivo presente na conferencia (), un graduado do noso departamento. Coñecíao, pero non realizáramos unha investigación conxunta antes. Mary Vernon () de Wisconsin fixeron unha presentación sobre o sistema multiprocesador que estaban a desenvolver en Wisconsin: Este Multicubo tiña un mecanismo de sincronización de hardware chamado Q on Sync Bit, que máis tarde pasou a chamarse Q on Lock Bit porque soaba como o queixo de Colby, polo que era un xogo de palabras. Se che gusta o multithreading, probablemente saibas que Colby acabou por converterse no mecanismo de sincronización para o estándar IEEE Scalable Coherent Interface. Era un mecanismo de bloqueo que creaba punteiros dunha caché a outra a nivel de hardware para que cada titular do bloqueo soubese de quen era a quenda. Cando John e eu soubemos disto, mirámonos e dixemos: por que facer isto a nivel de hardware? Non podemos conseguir o mesmo con comparar e intercambiar? Collemos un dos cadernos que había na aula e debuxámolo. mentres Mary continuaba coa súa presentación. Máis tarde implementámola, experimentamos con ela, a idea resultou exitosa e publicamos o artigo. Naquel momento, o tema parecíame só unha distracción divertida, despois do cal planeei volver aos sistemas operativos. Pero entón xurdiu outro problema na mesma dirección e, finalmente, a sincronización, o multithreading e as estruturas de datos convertéronse na miña principal especialidade. Como podes ver, todo aconteceu por accidente.
ВиталийLevo moito tempo familiarizado co bloqueo MCS, pero ata agora non sabía que era obra túa e non me decatara de que era un acrónimo dos teus apelidos.
Como sobrevivir nun mundo en constante cambio?
AlexTeño unha pregunta relacionada. Hai trinta ou corenta anos, había máis liberdade en diferentes especialidades. Se querías comezar unha carreira en sistemas multiproceso ou distribuídos, adiante; se querías traballar en sistemas operativos, non había problema. Cada campo tiña moitas preguntas abertas e poucos expertos. Agora, xurdiron especializacións estreitas: non só hai expertos xerais en sistemas operativos, senón que hai especialistas en sistemas específicos. O mesmo ocorre cos sistemas multiproceso e distribuídos. Pero o problema é que as nosas vidas son finitas; cada persoa só pode dedicar unhas poucas décadas á investigación. Como sobrevivimos neste novo mundo?
MichaelNon somos especiais neste sentido; o mesmo ocorreu noutros campos nalgún momento. Tiven a sorte de comezar a traballar en informática cando o campo estaba nos seus inicios. Algúns dos alicerces xa estaban sentados, pero todo aínda era moi inmaturo. Oportunidades como esta non se presentan con moita frecuencia. A enxeñaría eléctrica existe desde hai moito tempo, a física aínda máis e as matemáticas desde practicamente o principio dos tempos. Pero iso non significa que ninguén estea a facer descubrimentos interesantes en matemáticas. Aínda hai moitos problemas abertos, pero ao mesmo tempo, necesitamos aprender máis. Tes razón en que agora hai significativamente máis especializacións que antes, pero iso só significa que estamos na mesma situación que a maioría dos outros campos do esforzo humano.
AlexInterésame un aspecto máis práctico da cuestión. Teño formación en matemáticas e, durante os meus estudos, asistín con frecuencia a conferencias e traballei en diversos temas científicos. Descubrín que ninguén do público entendía as miñas charlas e, do mesmo xeito, as charlas doutras persoas só eran comprensibles para elas mesmas. Isto non é tan certo para temas de alto nivel, pero en canto comezas a afondar en algo, o público non pode seguir o ritmo. Como se supera isto?
MichaelNon sempre con éxito. Preparei hai pouco unha charla na 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 adaptala sobre a marcha. As diapositivas non se podían cambiar, polo que non tivo moito éxito; por iso, en xeral, intento non usar diapositivas. En xeral, o meu consello é ter en conta o teu público. Necesitas saber a quen te dirixes, o seu nivel de coñecemento e o que necesitan escoitar para apreciar o teu traballo.
ВиталийPoderías darme unha pista de que trataba esta charla?
MichaelPara ser sincero, preferiría non afondar demasiado neste tema para preservar o anonimato das persoas implicadas. A cuestión é que a miúdo afondamos demasiado nas complexidades do problema no que estamos a traballar, o que dificulta explicar ao comezo dunha charla por que o problema é interesante e importante e como se relaciona con temas que o público xa coñece. Na miña experiencia, esta é a habilidade coa que os estudantes teñen máis dificultades. E foi unha debilidade na miña charla recente. Unha charla ben estruturada debería conectar co público desde o principio, explicando exactamente cal é o problema e como se relaciona con temas que xa coñecen. O técnico que sexa esta introdución depende do público. Se é moi diversa, a charla pode ter varios pasos. A introdución debería ser accesible para todos e, ao final, pode ser demasiado difícil de seguir, pero a xente relativamente familiarizada co teu campo poderá entendelo todo.
Están os estudantes a volverse máis parvos? Tendencias globais, internacionalización.
AlexLevas varias décadas observando o alumnado. Os estudantes vólvense máis parvos ou máis intelixentes de década en década ou de ano en ano? En Rusia, os profesores quéixanse constantemente de que o alumnado se está volvendo máis parvo cada ano, e non está moi claro que facer ao respecto.
MichaelPódese escoitar moita negatividade de nós, os veteranos. Inconscientemente, tendemos a esperar que os estudantes absorban os 30 anos de experiencia que xa temos. Se teño unha comprensión máis profunda que a que tiña en 1985, por que non a teñen os estudantes? Probablemente porque teñen 20 anos, que che parece? Creo que o cambio máis significativo nas últimas décadas ten que ver coa composición demográfica: agora temos moitos máis estudantes internacionais, coa excepción dos canadenses. Antes había moitos canadenses porque estamos moi preto da fronteira canadense e os estudantes de alí podían volver para casa os fins de semana. Pero agora Canadá ten moitas boas universidades e os canadenses prefiren estudar na casa; viaxan moito menos aos Estados Unidos.
Alex: Cres que se trata dunha tendencia local ou global?
MichaelNon recordo exactamente quen, pero alguén dixo que o mundo é plano. O noso campo tornouse significativamente máis internacional. Antes, celebrábanse exclusivamente nos Estados Unidos, despois decidiron celebralos noutros países cada catro anos e agora celébranse en todo o mundo. Estes cambios tiveron un impacto aínda maior. , porque sempre foi unha organización máis internacional que a ACM. E hai presidentes de programa de China, India, Rusia, Alemaña e moitos outros países, porque agora mesmo están a suceder moitas cousas en todas partes.
AlexPero probablemente haxa algúns aspectos negativos nesta internacionalización?
MichaelEu diría que todos os aspectos negativos son políticos, non tecnolóxicos. Houbo un tempo no que o principal problema era que os Estados Unidos roubaban as persoas máis intelixentes e talentosas de países de todo o mundo. Agora, o principal problema son os xogos políticos entre diferentes países sobre visados e inmigración.
AlexÉ dicir, barreiras e cousas así. Entendido.
VladimirPersoalmente, teño curiosidade pola túa maneira de abordar a ensinanza dunha materia nova aos estudantes. Hai diferentes enfoques: podes centrarte en inspiralos para que proben algo novo ou podes centrarte máis nos detalles de como funciona unha tecnoloxía en particular. Cal prefires?
Traballo eficaz cos estudantes
Alex: E como atopas o maldito equilibrio entre o primeiro e o segundo?
MichaelO problema é que as clases non sempre saen como eu quero. Normalmente doulles aos estudantes material de lectura con antelación para que o poidan absorber, entendelo o mellor posible e formular preguntas sobre os puntos que non captaron. Despois, na clase, podemos centrarnos nos puntos máis difíciles e exploralos xuntos. Así é como me gusta ensinar. Pero dada a carga de traballo actual, non sempre teño a oportunidade de asegurarme de que se prepararon con antelación. Como resultado, acabo dedicando moito máis tempo a resumos xerais do que me gustaría. A pesar disto, intento manter as nosas clases interactivas. Se non, é máis doado gravar un vídeo unha vez para que os estudantes poidan velo na casa. O obxectivo das clases en directo é a interacción humana. Na clase, prefiro usar xiz e unha pizarra en lugar de diapositivas, agás en casos raros nos que un diagrama é demasiado complexo para mostralo na pizarra. Isto libérame de ter que seguir un plan de lección ríxido. Dado que non hai unha orde establecida na que presento o material, permíteme adaptarme ao público en función das preguntas que recibo. En xeral, tento que as clases sexan o máis interactivas posible, de xeito que o material que presento dependa das preguntas que me fagan.
VladimirIso é xenial. Pola miña experiencia, é bastante difícil conseguir preguntas dos oíntes. Mesmo se lles fas calquera pregunta con antelación, non importa o estúpida ou intelixente que sexa, seguen calados. Como lidias con isto?
MichaelRirás, pero se te quedas aí en silencio o tempo suficiente, tarde ou cedo todo o mundo se sentirá incómodo e alguén fará unha pregunta. Ou poderías facer unha simple pregunta técnica de si/non para determinar se a xente entendeu o que se acaba de dicir. Por exemplo, hai unha carreira de datos no exemplo dado? Quen pensa que si? Quen pensa que non? Quen non entende nada en absoluto, porque só se levantaron a metade das mans?
ВиталийE se respondes incorrectamente, serás expulsado da clase :)
MichaelSe non respondiches a nada, entón teño que facer unha pregunta. Teño que descubrir o que o alumno necesita saber para responder á pregunta que acabo de facer. Necesitan axudarme a axudalos. Estou disposto a adaptarme a eles para que poidan descubrir o problema. Pero se non sei o que lles pasa pola cabeza, non podo facelo. E se manteño aos alumnos en vilo o tempo suficiente, ás veces acaban facendo as preguntas correctas, preguntas que me permiten ver o que lles pasa pola cabeza.
AlexEstas preguntas ás veces levan a ideas nas que non se che ocorrera antes? Son inesperadas? Permitenche ver un problema baixo unha nova luz?
MichaelHai preguntas que abren unha nova forma de presentar o material. A miúdo, as preguntas levan a problemas interesantes que non tiña planeado tratar. O alumnado adoita dicirme que tendo a desviarme do tema da lección cando isto ocorre. E, segundo eles, esta adoita ser a parte máis interesante da lección. Moi raramente, só unhas poucas veces, o alumnado fixo preguntas que levaron a unha nova dirección na investigación e se desenvolveron nun artigo. Isto ocorre con moita máis frecuencia en conversas co alumnado que na clase, pero ocorreu ocasionalmente durante a clase.
AlexEntón, os estudantes fixéronche preguntas que máis tarde poderían usarse como base para un artigo?
Michael: Si.
ВиталийCon que frecuencia tes este tipo de conversas cos estudantes? Cando queren aprender máis do que se tratou na clase?
MichaelCos meus estudantes de posgrao... todo o tempo. Teño uns cinco ou seis deles, e sempre estamos falando de cousas. Conversas coma estas con estudantes que simplemente asisten ás miñas clases non son moi frecuentes. Aínda que me gustaría que ocorrese máis a miúdo. Sospeito que simplemente teñen medo de vir á oficina do profesorado durante o horario de titoría. Cada semestre, algúns estudantes conseguen superar esta barreira psicolóxica, e sempre é moi interesante falar con eles despois da clase. Non obstante, se todos os estudantes fosen tan valentes, simplemente non tería tempo. Entón, quizais todo funcione como debería.
ВиталийComo atopas tempo para interactuar co alumnado? Polo que eu sei, nos Estados Unidos os profesores están moi ocupados: solicitudes de bolsas e cousas semellantes.
MichaelSinceramente, traballar con estudantes é o aspecto do meu traballo que máis me gusta. Polo tanto, estou bastante motivado. A maior parte do tempo que paso no meu despacho dedícoo a varias reunións. Agora é verán, polo que a miña axenda é menos axitada, pero durante o curso escolar teño todo o traballo reservado todos os días de 9:00 a 17:00. Investigación, revisións, bolsas... só teño as tardes e os fins de semana para todo iso.
Como manterse ao día das últimas novidades na preparación de novos cursos e libros.
AlexSegues impartindo algunha das materias que levas impartindo durante moito tempo? Algo como Introdución á informática.
MichaelO primeiro que me vén á mente aquí é un curso de linguaxes de programación.
AlexEn que medida é diferente a versión actual deste curso da de hai 10, 20 ou 30 anos? Quizais a tendencia xeral sexa máis interesante que os detalles dun curso en particular.
MichaelO meu curso sobre linguaxes de programación era algo inusual no momento en que o creei. Comecei a impartilo a finais da década de 1980, substituíndo ao meu colega, Doug Baldwin (). O tema do curso só estaba relacionado tanxencialmente coa miña especialización, pero cando el marchou, decateime de que era o mellor candidato para impartilo. Non me gustaba ningún dos libros de texto existentes, así que acabei escribindo eu mesmo o libro de texto do curso. (Nota do editor: Trátase do libro) Actualmente úsase en máis de 200 universidades de todo o mundo. O meu enfoque é inusual porque mestura deliberadamente as preocupacións sobre o deseño e a implementación de linguaxes, centrándose nas interaccións entre estes aspectos en todos os dominios posibles. O enfoque central permaneceu inalterado, así como moitos dos conceptos básicos: abstraccións, espazos de nomes, modularidade, tipos. Non obstante, o conxunto de linguaxes utilizadas para demostrar estes conceptos cambiou por completo. Cando se creou o curso por primeira vez, incluía moitos exemplos en Pascal, pero hoxe en día, moitos dos meus estudantes nunca escoitaron falar desa linguaxe. Pero coñecen Swift, Go e Rust, polo que teño que falar das linguaxes que se usan hoxe en día. Ademais, os estudantes agora están ben versados en linguaxes de scripting, mentres que cando empecei a impartir este curso, estaba dedicado enteiramente a linguaxes compiladas. Agora, con todo, necesitamos moito material sobre Python, Ruby e mesmo Perl, porque é no que a xente escribe código hoxe en día, e moitas cousas interesantes están a suceder nestas linguaxes, incluída a área do deseño de linguaxes.
ВиталийEntón a miña seguinte pregunta está relacionada coa anterior. Como te mantés ao día neste eido? Sospeito que actualizar un curso coma este require moito traballo: necesitas comprender novas linguaxes e dominar os conceptos básicos. Como o fas?
MichaelNon podo dicir que sempre o consiga ao 100 %. Pero a maioría das veces, simplemente fago o que fai todo o mundo: leo internet. Se quero entender Rust, búscoo en Google, vou ao sitio web de Mozilla e leo a guía que hai alí. Iso é para o que está a suceder no desenvolvemento comercial. En canto ao ámbito académico, teño que seguir as charlas nas principais conferencias.
Conexións entre as empresas e o mundo académico
ВиталийFalemos da conexión entre a investigación empresarial e académica. Atopei varios artigos sobre a coherencia da caché na túa lista de traballos. Polo que eu entendo, no momento da súa publicación, os algoritmos de coherencia da caché eran inestables? Ou non se usaban amplamente. Que tan amplamente aceptadas foron as túas ideas na práctica?
MichaelNon estou moi seguro de que publicacións estás a falar. Fixen bastante traballo cos meus alumnos Bill Bolosky () e Leonidas Kontotanassis () a principios da década de 1990, traballando na xestión de memoria para máquinas Neumann. Naquel momento, a empresa aínda non entendía como construír correctamente un sistema multiprocesador: se construír soporte para o acceso remoto á memoria a nivel de hardware, se facer que a memoria fose distribuída, se cargar a caché desde a memoria remota ou se mover páxinas no sistema operativo. Bill e Leonidas estaban traballando nesta área e explorando enfoques que non implicaban a carga remota da caché. Isto non estaba directamente relacionado coa coherencia da caché, pero seguía sendo un traballo na xestión de memoria NUMA e, máis tarde, converteuse na base dos enfoques modernos para a colocación de páxinas nos sistemas operativos modernos. En xeral, Bill e Leonidas fixeron un traballo importante, aínda que non o máis influente no campo; moitas outras persoas estaban traballando no mesmo nese momento. Máis tarde, traballei na coherencia da caché no contexto da memoria transaccional de hardware. O grupo co que traballei neste problema acabou recibindo varias patentes. Hai algunhas ideas interesantes detrás delas, pero non creo que se implementen finalmente. En calquera caso, é difícil para min xulgar a súa rendibilidade.
Alex: Neste sentido, unha pregunta máis persoal: que importancia ten para vostede ver as súas ideas postas en práctica? Ou non pensa niso?
MichaelEncántame facer esta pregunta nas entrevistas con outras persoas, xa sexan candidatos ou persoas interesadas en traballar no departamento. Non creo que haxa unha resposta correcta. A xente que fai cousas interesantes pode ter motivacións moi diferentes. Atraéme os problemas porque persoalmente os atopo interesantes, non polo seu uso práctico. Pero, por outra banda, cando algo interesante atopa un uso, gústame moito. Entón non é tan sinxelo. Pero ao comezo dun proxecto, non me impulsa a idea do seu uso final no mundo, senón a coherencia da idea e o desexo de explorala e ver que sae dela. Se finalmente produce beneficios prácticos, xenial.
AlexGrazas á túa formación e experiencia, estás en mellor posición que moitos outros para avaliar o valor das ideas doutras persoas. Podes comparalas e determinar cales funcionan mellor con cales. Seguro que tes unha opinión sobre as tecnoloxías que empregan actualmente na práctica os principais fabricantes como Intel. Na túa opinión, é o camiño que están a tomar estas empresas o correcto?
MichaelA práctica sempre xira arredor do que pode ter éxito comercial, é dicir, xerar beneficios, e é mellor preguntarlle a alguén máis sobre iso. O meu traballo dá lugar principalmente a publicacións e, no campo dos sistemas operativos, avalíanse por métricas de rendemento: velocidade, consumo de enerxía, tamaño do código. Pero sempre me pareceu que estes resultados empíricos se engaden aos artigos só para que poidan ser publicados, mentres que os verdadeiros motivos de traballo das persoas son estéticos. Os investigadores avalían as solucións desde unha perspectiva artística; preocúpanse pola elegancia das súas ideas e intentan crear algo mellor que os enfoques existentes. Os investigadores están impulsados por motivos persoais, subxectivos e estéticos. Pero non se pode escribir sobre isto no propio artigo; estas cousas non son argumentos para o comité do programa. Afortunadamente, as solucións elegantes adoitan ser rápidas e baratas. Uns dez dos meus colegas e eu discutimos este tema hai uns 15 anos e acabamos escribindo un artigo sobre el. Creo que aínda se pode atopar agora; chámase ou algo así, ten máis dunha ducia de autores. Este é o único artigo no que son autor xunto con , así que se buscas o seu nome na miña lista de publicacións, atoparás o que estás buscando. Fala sobre a avaliación da investigación en sistemas e a importancia da elegancia.
AlexEntón, hai unha diferenza entre os estándares do que se considera un bo resultado na ciencia e nos negocios. Na ciencia, avalíase o rendemento, o consumo de enerxía, o TDP, a facilidade de implementación e moito máis. Tedes a oportunidade de levar a cabo este tipo de investigación na universidade? Tedes un laboratorio con diferentes máquinas e diferentes arquitecturas onde se poderían realizar experimentos?
MichaelSi, o noso departamento ten moitas máquinas interesantes. Normalmente son pequenas; temos un pequeno clúster e moitos sistemas multiprocesador con varios aceleradores. Tamén temos un enorme centro de computación no campus que serve a investigadores de varias ducias de disciplinas diferentes. Ten uns mil nodos e vinte mil núcleos, todos con Linux. Se xorde a necesidade, sempre podemos mercar algo de AWS. Polo tanto, non temos limitacións significativas de hardware.
AlexCal era a situación hai trinta anos? Houbo algún problema entón?
MichaelAs cousas eran un pouco diferentes naquel entón. A mediados e finais da década de 1980, críase que a ciencia carecía de recursos informáticos. Para remediar esta situación, a Fundación Nacional para a Ciencia ) creou o programa de Investigación Experimental Coordinada (CER). O seu obxectivo era proporcionar infraestrutura informática para os departamentos de informática, e marcou unha diferenza significativa. Co diñeiro que proporcionou, compramos un BBN Butterfly de 128 nodos na Universidade de Rochester en 1984, un ano antes da miña chegada. Naquel momento, era o sistema multiprocesador de memoria compartida máis grande do mundo. Tiña 128 procesadores, cada un nunha placa base separada, ocupando catro racks. Cada procesador tiña un megabyte de memoria; 128 megabytes de RAM era unha cantidade inimaxinable naquel momento. Implementamos por primeira vez o bloqueo MCS nesta máquina.
AlexEntón, se o entendín ben, o problema do hardware xa está resolto?
MichaelEn xeral, si. Hai algunhas advertencias: primeiro, se estás a traballar en arquitectura de ordenadores a nivel de chip, é difícil facelo no ámbito académico porque hai ferramentas moito máis sofisticadas para iso nos negocios. Se necesitas algo menor de 10 nanómetros, terás que externalizalo. É moito máis doado ser investigador en Intel nese campo. Se estás a traballar en comunicacións ópticas en chips ou memoria de estado sólido, atoparás tecnoloxías nos negocios que aínda non están dispoñibles no ámbito académico, polo que tes que formar alianzas. Por exemplo, Stephen Swanson () creado para novas tecnoloxías de memoria. Esta estratexia non sempre funciona, pero nalgúns casos pode ter bastante éxito. Ademais, desenvolver os sistemas informáticos máis potentes é máis difícil na ciencia. Os maiores proxectos de supercomputación que se están a realizar actualmente nos Estados Unidos, no Xapón e na China concéntranse nos negocios.
Poñendo ideas en práctica. MCS, MS, CLH, JSR 166, traballando con Doug Lee e moito máis.
ВиталийXa falaches de como comezaches a traballar en algoritmos de sincronización. Tes dous artigos moi coñecidos sobre и , que nun certo sentido foron implementadas 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: No caso da cola, parece que pasaron uns 10 anos.
MichaelAntes de que estas funcionalidades aparecesen na biblioteca estándar de Java?
ВиталийSi. Que fixeches para que isto sucedese? Ou non fixeches nada?
MichaelPodo contarvos como chegou a cola de MS a Java 5. Uns anos antes de que saíse, estaba traballando co grupo de Mark Moyers en Sun Microsystems no seu laboratorio nos arredores de Boston. Organizou un obradoiro para algúns dos seus amigos que estaban traballando en problemas interesantes de multithreading, porque quería atopar temas que se puidesen vender á súa empresa. Foi alí onde coñecín por primeira vez a Doug Lea. Doug, eu e unhas 25 persoas máis de Sun estabamos falando da presentación de Doug sobre , que máis tarde se converteu en java.util.concurrent. Polo camiño, Doug mencionou que quería usar a cola de MS, pero necesitaba un contador para que a interface manexase o número de elementos na cola. Isto significaba que un método separado, atómico, preciso e rápido, tería que facelo. Suxerín simplemente engadir os números de serie aos nodos, tomar o número de serie do primeiro nodo e do último e restar un do outro. Doug rascouse a cabeza, dixo: "Por que non?", e finalmente fixo precisamente iso. Falamos sobre a implementación deste enfoque nunha biblioteca, pero Doug fixo a maior parte do traballo el mesmo. Finalmente, conseguiu establecer un excelente soporte multiproceso en Java.
AlexEntón, se o entendín correctamente, o método .size() debería ter formado parte da interface de cola estándar e debería ter unha complexidade algorítmica de O(1)?
MichaelSi, e ademais disto, requírese un contador separado.
AlexPorque se chamas o método .size() en Java, espérase que o resultado estea dispoñible inmediatamente, non en función do tamaño real da colección. Entendido, grazas.
MichaelUns anos máis tarde traballei en estruturas de datos duais co meu alumno Bill Scherer; diso tratará o meu artigo. Doug contactou connosco e díxonos que podía usalos no Java Executor Framework. Xunto con Bill, creou dúas implementacións, as chamadas colas xustas e inxustas. Eu asesorei sobre este proxecto, aínda que non participei na escritura do código. Como resultado, a velocidade dos executores aumentou significativamente.
VladimirAlgunha vez atopaches implementacións incorrectas dos teus algoritmos ou solicitudes de novas funcionalidades? Polo xeral, a práctica debería coincidir coa teoría, pero a miúdo diverxen. Digamos que escribiches un algoritmo e funciona sobre o papel, pero a xente que o implementa comeza a pedirche máis funcionalidades ou algunha personalización. Algunha vez atopaches situacións semellantes?
MichaelO único exemplo no que alguén se achegou a min e me preguntou "como implementalo" foi a pregunta de Doug, que xa mencionei. Pero houbo varios casos nos que se fixeron cambios interesantes para satisfacer necesidades prácticas. Por exemplo, o equipo K42 de IBM converteu o bloqueo MCS e creou unha interface estándar que eliminou a necesidade de pasar o nodo da cola de ida e volta entre as rutinas de adquisición e liberación. Esta interface estándar fixo que a idea, fermosa en teoría, funcionase na práctica. Sorprendentemente, nunca publicaron un artigo sobre ela e, aínda que recibiron unha patente, foi abandonada máis tarde. O concepto foi brillante e tento falar del sempre que podo.
Houbo outros casos nos que a xente fixo melloras nos algoritmos que publiquei. Por exemplo, a cola MS ten un mecanismo de configuración de dúas etapas, o que significaba que había dous CAS na ruta crítica da cola. En máquinas antigas, os CAS eran bastante caros. Intel e outros fabricantes optimizáronos ben recentemente, pero naqueles tempos eran instrucións de 30 ciclos, polo que ter máis dun na ruta crítica non era desexable. Como resultado, desenvolveuse unha gran cola similar á cola MS, pero que só tiña unha operación atómica na ruta crítica. Isto conseguiuse permitindo que unha operación levase O(n) tempo en lugar de O(1) tempo dentro dun determinado intervalo de tempo. Isto era improbable, pero posible. Isto ocorreu porque nalgúns puntos o algoritmo percorría a cola desde o principio ata a posición actual na cola. En xeral, o algoritmo resultou ser moi exitoso. Polo que sei, non se usa moi amplamente, en parte porque as operacións atómicas requiren significativamente menos recursos que antes. Pero a idea era xenial. Tamén me gusta moito o traballo de Dave Dice en Oracle. Todo o que fai é moi práctico e usa o hardware con moita habilidade. Participou nunha parte importante dos algoritmos de sincronización compatibles con NUMA e das estruturas de datos multifío.
VladimirCando escribes algoritmos ou ensinas aos estudantes, os resultados do teu traballo non son visibles de inmediato. Á comunidade lévalle algún tempo familiarizarse, por exemplo, cun novo artigo. Un novo algoritmo non atopa aplicación inmediata.
MichaelNon está nada claro de inmediato se un artigo será influente ou non. Creo que sería interesante realizar un estudo dos artigos que gañaron premios en congresos. É dicir, analizar os artigos que a xente dos comités de programa nese momento consideraba os mellores. Deberíamos tentar calcular, en función do número de citas e o impacto empresarial, a influencia real destes artigos 10, 20 ou 25 anos despois. Dubido que haxa unha forte correlación entre estes dous parámetros. Non será cero, pero o máis probable é que sexa significativamente máis débil do que nos gustaría. Moitas ideas permanecen sen reclamar durante moito tempo antes de gañar forza. Por exemplo, tomemos a memoria transaccional. Pasaron máis de 10 anos desde a publicación do artigo orixinal ata que a xente comezou a construír máquinas con ela. E pasaron 20 anos completos antes de que esta memoria aparecese en produtos comerciais. Durante moito tempo, ninguén prestou atención ao artigo e, a continuación, o número de citas aumentou drasticamente. Sería difícil predicir isto con antelación. Por outra banda, ás veces as ideas atopan implementación inmediata. Hai uns anos, escribín xunto con Joe Izraelevitz un artigo para DISC que propoñía unha nova definición formal de corrección para as estruturas de datos persistentes que se podían usar 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. Varios grupos diferentes o adoptaron e finalmente converteuse na definición estándar das estruturas de datos persistentes. O cal é certamente algo bo.
VladimirEmpregas algunha técnica de avaliación? Tentas sequera avaliar os teus artigos ou os teus alumnos? En canto a se a persoa á que ensinaches está no bo camiño.
MichaelComo todo o mundo, estou máis centrado no que estou a traballar actualmente. Como todo o mundo, de cando en vez consulto Google Scholar para ver se se citan os meus traballos anteriores, pero iso é principalmente por curiosidade. Estou mergullado principalmente no que están a facer agora os meus alumnos. En canto á avaliación do traballo actual, é en parte unha cuestión de estética: o que é elegante e o que non. E no día a día, as preguntas abertas xogan un papel importante. Por exemplo, un alumno pode vir cun gráfico dalgúns resultados e nós trataremos de descubrir por que o gráfico se comporta de forma estraña. En xeral, no noso traballo, estamos constantemente a tentar descubrir cousas que aínda non entendemos.
Memoria transaccional
ВиталийQuizais deberiamos falar un pouco sobre a memoria transaccional?
MichaelCreo que paga a pena dicir polo menos un pouco, porque lle dediquei moito esforzo. É o tema sobre o que publiquei máis que calquera outro. Pero ao mesmo tempo, curiosamente, sempre fun bastante escéptico sobre a memoria transaccional. Na miña opinión, (M. Herlihy, J.E.B. Moss) publicouse antes de tempo. A principios da década de 1990, propuxeron que a memoria transaccional podería axudar aos programadores talentosos que traballaban con estruturas de datos multiproceso, de xeito que estas estruturas puidesen ser usadas como bibliotecas por programadores comúns. Noutras palabras, sería unha bendición para Doug Lees traballando no seu JSR 166. Pero a memoria transaccional non pretendía facilitar a programación multiproceso. E, con todo, así é precisamente como se percibía a principios da década de 2000, cando gañou popularidade. Presentouse como unha forma de resolver o problema da programación paralela. Esta abordaxe sempre me pareceu imposible. A memoria transaccional só podía simplificar a escritura de estruturas de datos paralelas. E iso, na miña opinión, é o que conseguiu.
Sobre a complexidade de escribir código multifío
AlexMoi 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 Thompson, así como con programadores que traballaban en bibliotecas multiproceso. (Nota do editor: Martin Thompson é un desenvolvedor moi coñecido; escribiu и E tamén ten na nosa conferencia Joker 2015, gravación de vídeo El é o mesmo. esta conferencia, (Tamén accesible). Segundo eles, o principal reto é facer que os algoritmos sexan rápidos e fáciles de usar. Polo tanto, están a tentar superar esta barreira e atraer a tanta xente como sexa posible a este campo. Que opinas disto?
MichaelEste é o principal problema do multithreading: como conseguir un alto rendemento sen aumentar a complexidade do sistema.
AlexPorque cando tentan evitar a complexidade, o algoritmo vólvese menos xeral.
MichaelA clave aquí reside en abstraccións deseñadas correctamente. Creo que esta é a clave dos sistemas informáticos como campo en xeral. A Butler Lampson gústalle usar este termo e chámanos "mercaderes de abstraccións". As tecnoloxías sinxelas non existen hoxe en día. Os procesadores que usamos conteñen 10 millóns de transistores: a simplicidade está fóra de cuestión. Ao mesmo tempo, o ISA é significativamente máis sinxelo que o procesador, xa que traballamos arreo para garantir un alto rendemento e unha interface relativamente sinxela para el. Pero mesmo con el, non todo vai ben. O mesmo problema existe cos aceleradores que agora aparecen no mercado. Xorden preguntas: como crear a interface correcta para a GPU, o motor de cifrado, a compresión, o motor de transcodificación, o motor de álxebra lineal ou mesmo unha FPGA máis flexible. Como crear unha interface que garanta a facilidade de uso e oculte a complexidade? Non desfacerse dela, senón ocultala ao programador medio.
AlexEntendo que aínda temos unha barreira para comprender as abstraccións. Tomemos o modelo da memoria; na nosa etapa de desenvolvemento científico e tecnolóxico, é unha das abstraccións máis importantes. Divide a todos os programadores en dous grupos: a maioría (os que non o entenden) e a minoría (os que si o entenden ou cren que o entenden).
MichaelÉ unha boa pregunta: algún de nós entende realmente o modelo da memoria?
ВиталийEspecialmente en C++.
MichaelFala con Hans Boehm algunha vez. É unha das persoas máis intelixentes que coñezo, un experto destacado en modelos de memoria. Dirache de inmediato que non entende moito diso. Pero volvendo á cuestión das abstraccións, creo que a idea máis importante no campo dos modelos de memoria nos últimos 30 anos foi expresada por (Nota do editor: hai dispoñible unha lista completa de publicacións) ).
AlexA miña pregunta é: esta barreira provén da propia natureza do concepto?
MichaelNon. Sarita concluíu que, coa estratexia axeitada, pódese ocultar con éxito toda a complexidade, conseguir un alto rendemento e proporcionarlle ao programador unha API sinxela. E se se segue esta API, pódese conseguir consistencia secuencial. Creo que este é o modelo correcto. Escribe código sen carreiras de datos e obterás consistencia secuencial. Por suposto, para reducir a probabilidade de carreiras de datos, necesitas ferramentas especializadas, pero iso é outra cuestión.
VladimirHoubo algún caso na túa carreira no que un problema que parecía resolto se convertese de súpeto nun desastre ou no que resultase irresoluble? Por exemplo, en teoría, é posible factorizar calquera número ou determinar se un número é primo. Pero na práctica, isto pode ser difícil; co hardware actual, é difícil factorizar números. Algunha vez che pasou algo semellante?
MichaelNon se me ocorre nada semellante de inmediato. Houbo momentos nos que pensei que non había nada máis que facer nunha determinada zona e, de súpeto, aconteceu algo novo e interesante. Por exemplo, pensei que o campo das colas ilimitadas xa alcanzara a madurez. Despois dalgunhas melloras na cola do MNS, xa non aconteceu nada especial. E entón Morrison (Adam Morrison) e Afek (Yehuda Afek) inventaron Tornouse evidente que era posible unha cola multifío ilimitada, coa instrución de busca e incremento na ruta crítica a maior parte do tempo. E isto permitiu unha mellora dunha orde de magnitude no rendemento. Non é que non soubésemos xa que a busca e incremento era unha característica moi útil. Eric Freudenthal escribiu sobre isto no seu artigo sobre o ultracomputador con Allan Gottlieb a finais da década de 1980, pero iso era para colas limitadas. Morrison e Afek puideron usar a busca e incremento nunha cola ilimitada.
Novas arquitecturas: está a memoria transaccional a piques de gañar?
VladimirEstás atento a novas solucións arquitectónicas que poderían ser útiles para os algoritmos?
MichaelPor suposto, hai moitas cousas que me gustaría ver implementadas.
Vladimir: E cales, por exemplo?
MichaelPrimeiro de todo, unhas cantas extensións sinxelas para a nosa memoria transaccional a nivel de hardware nos procesadores Intel e IBM. En particular, gustaríame facer que as cargas e almacenamentos non transaccionais estean dispoñibles inmediatamente dentro das transaccións. Levan inmediatamente a bucles na secuencia "acontece antes", polo que poden ser complicados. Pero se mantemos capas de abstracción, hai moitas cousas moi interesantes que se poden facer fóra dunha transacción mentres está en curso. Non sei o difícil que sería implementar isto, pero sería moi útil.
Outra característica útil é a carga da caché desde a memoria remota. Creo que isto se implementará tarde ou cedo. Esta tecnoloxía permitirá a creación de sistemas con memoria desagregada. Será posible almacenar, por exemplo, 100 terabytes de memoria non volátil nun rack, e o sistema operativo decidirá dinamicamente que seccións desta memoria deben mapearse ao espazo de enderezos físicos dos procesadores. Isto sería extremadamente útil para a computación na nube, xa que permitiría asignar grandes cantidades de memoria ás tarefas que o requiren. Creo que alguén acabará por facer isto.
ВиталийPara concluír a conversa sobre a memoria transaccional, teño outra pregunta relacionada. A memoria transaccional acabará substituíndo as estruturas de datos multiproceso estándar?
Michael: Non. As transaccións son un mecanismo especulativo. A nivel de programación, son bloqueos atómicos, pero internamente, son especulacións. Este tipo de predición só funciona se a maioría das adiviñas son correctas. É por iso que a memoria transaccional funciona ben cando os fíos apenas interactúan entre si e só necesitas asegurarte de que non haxa interacción. Pero se unha mensaxe comeza entre fíos, as transaccións son de pouca utilidade. Permíteme aclarar: estamos a falar do caso no que as transaccións se envolven arredor de toda a operación atómica. Aínda se poden usar con éxito como bloques de construción para estruturas de datos multifío. Por exemplo, se necesitas un CAS de tres palabras e necesitas multifío tres cousas pequenas no medio dun algoritmo verdadeiramente multifío que funciona con vinte fíos simultaneamente. En resumo, as transaccións poden ser útiles, pero non eliminan a necesidade de deseñar correctamente estruturas de datos multifío.
Memoria non volátil, Optane DIMM, dispositivos ultrarrápidos.
ВиталийO último que me gustaría comentar é o teu tema de investigación actual: a memoria non volátil. Que podemos esperar neste eido no futuro próximo? Tes coñecemento dalgunha implementación eficiente existente?
MichaelNon son un experto en hardware, só sei o que leo nas noticias e o que me din os meus compañeiros. Todo o mundo xa ouviu que Intel está a vender , que teñen aproximadamente 3 veces a latencia de lectura e 10 veces a latencia de escritura da RAM dinámica. Pronto estarán dispoñibles en capacidades moi grandes. É curioso pensar que poderías ter un portátil con varios terabytes de RAM direccionable por bytes. É bastante posible que en 10 anos decidamos usar esta nova tecnoloxía do mesmo xeito que usamos a DRAM, simplemente seguir engadindo máis capacidade. Pero a non volatilidade abre posibilidades 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 por bloques. Isto significa que non temos que serializar todo o que necesitamos en ficheiros estruturados por bloques, senón transferilo dunha execución de programa a outra. Isto ten moitas implicacións importantes para os sistemas operativos, os entornos de execución e o almacenamento de datos distribuído. É unha área moi interesante na que traballar. Persoalmente, é difícil para min predicir a que levará todo isto, pero os problemas aquí son extremadamente interesantes. Pode haber cambios revolucionarios aquí, e derivan de forma moi natural do traballo sobre subprocesos múltiples, xa que a recuperación de fallos é un proceso "subproceso múltiple" xunto co 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 a eles desde o espazo de usuario con control de políticas a nivel de sistema. Nos últimos anos, houbo unha tendencia a trasladar o acceso dos dispositivos ao espazo de usuario. Isto débese a que a pila TCP-IP do kernel non pode funcionar enriba dunha interface de rede que require un novo paquete cada 5 microsegundos; simplemente non se mantén ao día. Polo tanto, os provedores proporcionan acceso directo aos dispositivos. Non obstante, isto significa que o sistema operativo perde o control sobre o proceso e non pode garantir o acceso axeitado aos dispositivos para as aplicacións da competencia. O noso grupo de investigación cre que se pode evitar este inconveniente. Presentaremos un artigo sobre isto no USENIX ATC este mes. Está relacionado co traballo sobre a persistencia, xa que a memoria persistente duradeira e direccionable por bytes é esencialmente un dispositivo con E/S ultrarrápida ao que se debe acceder no espazo de usuario. Estes estudos permiten novas abordaxes para os micronúcleos, os exonúcleos e outros intentos tradicionais de mover de forma segura a funcionalidade do kernel do sistema operativo ao espazo de usuario.
VladimirA memoria direccionable por bytes é estupenda, pero hai un límite físico: a velocidade da luz. Isto significa que inevitablemente haberá un atraso ao interactuar co dispositivo.
Michael: Totalmente correcto.
VladimirHaberá capacidade suficiente para facer fronte ás novas cargas?
MichaelÉ unha gran pregunta, pero é difícil para min responder. A idea do procesamento na memoria existe desde hai bastante tempo; é moi interesante, pero tamén moi complexa. Non traballei nese eido, pero sería xenial se se fixesen algúns descubrimentos. Síntoo, non teño nada máis que engadir.
VladimirHai outro problema. Será imposible colocar cantidades novas e significativamente maiores de RAM na CPU. Polo tanto, debido ás limitacións físicas, esta RAM debe estar illada.
MichaelAquí, todo depende do número de defectos na produción de circuítos integrados. Se fose posible crear obleas de semicondutores totalmente libres de defectos, poderíase fabricar un microchip completo con elas. Pero agora mesmo non podemos fabricar microchips máis grandes que selos postais.
VladimirPero seguimos falando de tamaños enormes, centímetros. Isto inevitablemente afecta á latencia.
MichaelSi. Non hai nada que poidas facer coa velocidade da luz.
Vladimir: Por desgraza.
A seguinte gran tendencia. Estruturas de datos duais. Hydra.
ВиталийSegundo o que eu entendo, es moi rápido para adoptar novas tendencias. Fuches un dos primeiros en traballar na memoria transaccional e un dos primeiros en memoria non volátil. Cal cres que será a próxima gran tendencia? Ou quizais sexa un segredo?
MichaelSinceramente, non o sei. Espero poder detectar algo novo cando xurda. Non tiven a sorte de inventar eu só ningún campo novo, pero si que tiven a sorte de ter vantaxe sobre novos campos creados por outros. Espero poder seguir facéndoo no futuro.
AlexA última pregunta desta entrevista é sobre a túa presentación en Hydra e a túa clase na escola. Se ben o entendín, a túa charla na escola tratará sobre algoritmos sen bloqueos e a túa charla na conferencia tratará sobre estruturas de datos duais. Poderías dicir unhas palabras sobre estas charlas?
MichaelXa tocamos algúns destes temas nesta entrevista. Trátase dun traballo que fixen co meu alumno Bill Scherer. El escribiu a súa disertación sobre iso, e Doug Lee tamén contribuíu a el, e finalmente converteuse en parte das colas síncronas multifío na biblioteca Java. Supoñamos que estás a ler e escribir nunha estrutura de datos sen bloqueo, o que significa que cada operación ten un número limitado de instrucións na ruta crítica. Se intentas recuperar datos dun contedor baleiro ou intentas recuperar datos específicos que non están nese contedor, dise inmediatamente que non se pode facer. Pero este comportamento pode ser inaceptable se un fío realmente necesita estes datos. O primeiro que se che vén á mente é crear un bucle que pregunte constantemente se chegaron os datos requiridos. Pero iso crea interferencias para todos os demais. Ademais, con esta estratexia, poderías esperar 10 minutos e, a continuación, podería aparecer outro fío e obter accidentalmente os datos requiridos primeiro. As estruturas de datos duais aínda carecen de bloqueos, pero permiten unha espera de fío adecuada. O termo "dual" significa que a estrutura contén datos ou solicitudes de datos; chamémoslles antidatos. Entón, se intentas recuperar algo dun contedor baleiro, colocarase unha solicitude no contedor. Agora un fío pode esperar unha solicitude sen molestar a ninguén máis. Ademais, a estrutura de datos prioriza as solicitudes, de xeito que ao recibilas, as pasa ao fío axeitado. Isto resulta nun mecanismo sen bloqueos que ten unha especificación formal e un bo rendemento na práctica.
AlexCales son as túas expectativas para esta estrutura de datos? Mellorará o rendemento en todos os casos típicos ou é máis axeitada para situacións específicas?
MichaelÉ útil cando, en primeiro lugar, se necesita un contedor sen bloqueos e, en segundo lugar, é necesario esperar cando é necesario recuperar datos do contedor que aínda non está alí. Polo que eu sei, a nosa estrutura ofrece un comportamento óptimo cando se cumpren estas dúas condicións. Polo tanto, recomendo usala nestes casos. A principal vantaxe das estruturas de datos sen bloqueos é que evitan problemas de rendemento. E a espera é moi importante en moitos algoritmos cando se transfiren datos dun fío a outro.
ВиталийDéixame aclarar: falarás do mesmo tanto na escola como na conferencia?
MichaelNa escola Esta lección centrarase nas estruturas de datos multifío en xeral, cunha introdución xeral aos principios básicos ao principio. Supoño que o público sabe o que son os fíos e está familiarizado cos bloqueos. Baseándome nesta base, falarei sobre as estruturas de datos sen bloqueos. Ofrecerei unha visión xeral dos problemas máis importantes nesta área, abordando temas como a xestión da memoria. Non creo que haxa nada máis complexo que a cola de MS.
AlexTes pensado tratar as estruturas de datos duais ao final da túa clase na escola?
MichaelMencionareinos, pero non lles dedicarei moito tempo. Darei unha charla sobre Hydra. Abarcará o proxecto que finalmente se converteu en parte de Java, así como o meu traballo con Joe Israelevich na creación dunha variante de dobre cola do LCRQ e a creación dunha construción case universal para estruturas de datos duais.
AlexEntón, a clase maxistral da escola pódese recomendar para principiantes e a clase maxistral sobre estruturas de datos duais en Hydra é para persoas con algo de experiencia?
MichaelCorríxeme se me equivoco, pero o público de Hydra será bastante diverso, incluíndo moitos expertos en Java e xente que non traballa especificamente con programación multiproceso.
ВиталийSi, iso é certo.
Alex: Polo menos iso esperamos.
MichaelNeste caso, atopareime co mesmo problema co que comezamos esta entrevista: como facer unha reportaxe que sexa o suficientemente rica en detalles técnicos e accesible para todos os oíntes.
ВиталийImpartirás a túa presentación como farías unha clase maxistral? É dicir, interactuarás co público e adaptaraste á situación?
MichaelTemo que iso non funcionará porque a presentación terá diapositivas. As diapositivas son importantes cando o público fala inicialmente diferentes idiomas. Moitos terán dificultades para entenderme en inglés, especialmente se falo demasiado rápido. Escollín estes temas especificamente porque Pediume que falase sobre estruturas de datos sen bloqueos na Escola SPTDC; despois necesitaban unha charla para a conferencia do Grupo de Usuarios de Java e eu quería escoller algo que fose de interese específico para os programadores de Java. O xeito máis doado era falar sobre as características da biblioteca de Java nas que traballara dun xeito ou doutro.
AlexSupoñemos que o público de Hydra xa sabe algo sobre programación sen bloqueos e quizais teña algunha experiencia neste eido. Pero isto é só unha suposición; a situación quedará máis clara na propia conferencia. En calquera caso, grazas polo seu tempo. Seguro que os nosos lectores atoparán a entrevista moi interesante. Moitas grazas!
ВиталийGrazas.
MichaelEstarei encantado de coñecerte en San Petersburgo.
AlexNós tamén temos unha cidade fermosa. Estiveches algunha vez aquí?
MichaelNon, nunca estiven en Rusia. Pero San Petersburgo sempre estivo na miña lista de lugares nos que nunca estiven pero que quero visitar, así que me emocionou recibir a invitación.
AlexPor certo, ofreceremos un programa de visitas guiadas para os relatores. Moitas grazas pola entrevista e que teñas un bo día!
Podes continuar a conversa con Michael na conferencia Hydra 2019, que se celebrará os días 11 e 12 de xullo de 2019 en San Petersburgo. Presentará un informe. . As entradas pódense mercar .
Fonte: www.habr.com
