- com a professor d'informàtica a la Universitat de Rochester, i a la seva universitat natal de Wisconsin–Madison va ser degà durant cinc anys. Investiga i ensenya als estudiants sobre programació paral·lela i distribuïda i disseny de llenguatges.
El món coneix a Michael pel llibre de text , què passa amb la feina va rebre el Premi Dijkstra com un dels més famosos en el camp de la informàtica distribuïda. També el coneixeu com l'autor d'aquest algorisme .
Juntament amb Doug Lee, va desenvolupar els algorismes sense bloqueig i les cues sincròniques que alimenten les biblioteques de Java. Implementació a JavaSE 6 va millorar el rendiment en 10 vegades ThreadPoolExecutor.
Contingut:
- Carrera inicial a la Universitat de Rochester. Projecte Charlotte, llengua Lynx;
- Interfície coherent escalable IEEE, bloqueig MCS;
- Supervivència en un món en constant canvi;
- Els estudiants es tornen més tontos? Tendències globals, internacionalització;
- Treball eficaç amb els alumnes;
- Com estar al dia amb la preparació de nous cursos i llibres;
- Vincles entre empresa i àmbit acadèmic;
- Aplicació pràctica d'idees. MCS, MS, CLH, JSR 166, treballant amb Doug Lee i més;
- Memòria transaccional;
- Noves arquitectures. La victòria de la memòria transaccional està a prop;
- Memòria no volàtil, DIMM Optane, dispositius ultra ràpids;
- La propera gran tendència. Estructures de dades duals. Hidra.
Les entrevistes les realitzen:
Vitali Aksenov — actualment és postdoctoral a IST Àustria i membre del Departament de Tecnologies Informàtiques de la Universitat ITMO. Realitza investigacions en l'àmbit de la teoria i la pràctica d'estructures de dades competitives. Abans de treballar a IST, es va doctorar a la Universitat Diderot de París i a la Universitat ITMO sota la supervisió del professor Peter Kuznetsov.
Alexei Fedorov és productor de JUG Ru Group, una empresa russa que organitza conferències per a desenvolupadors. Alexey va participar en la preparació de més de 50 conferències, i el seu currículum conté des de la posició d'enginyer de desenvolupament a Oracle (JCK, Java Platform Group) fins a la posició de desenvolupador a Odnoklassniki.
Vladimir Sitnikov és enginyer a Netcracker. Durant deu anys treballa en el rendiment i l'escalabilitat del sistema operatiu NetCracker, programari utilitzat pels operadors de telecomunicacions per automatitzar els processos de gestió d'equips de xarxa i xarxa. Interessat en problemes de rendiment de Java i Oracle Database. Autor de més d'una dotzena de millores de rendiment al controlador JDBC oficial de PostgreSQL.
Carrera inicial a la Universitat de Rochester. Projecte Charlotte, llenguatge Lynx.
Alex: Per començar, volia dir-vos que a Rússia a tots ens agrada molt la informàtica, la ciència de dades i els algorismes. És francament obscè. Ho hem llegit tot . Per tant, la propera conferència, l'escola i aquesta entrevista en si haurien de ser molt populars. Hem rebut moltes preguntes per a aquesta entrevista d'estudiants, programadors i membres de la comunitat, així que estem molt agraïts per aquesta oportunitat. La informàtica té el mateix amor als EUA?
Michael: El nostre camp és tan divers, té tantes direccions i afecta la societat de tantes maneres diferents que em costa donar-te una resposta definitiva. Però el fet és que ha provocat grans canvis en els negocis, la indústria, l'art i la societat en general durant els darrers 30 anys.
Виталий: Comencem amb alguna cosa llunyana. En moltes universitats hi ha alguna cosa com l'especialització en una àrea concreta. Per a la Carnegie Mellon University això és informàtica paral·lela, per al MIT és criptografia, robots i multithreading. Hi ha aquesta especialització a la Universitat de Rochester?
Michael: Per ser sincer, diria que la CMU i el MIT s'especialitzen en totes les àrees. El nostre departament sempre ha prestat la màxima atenció a la intel·ligència artificial. La meitat de les persones que treballen per a nosaltres es dediquen a la IA o a la interacció home-ordinador; aquesta proporció és més alta que en altres departaments, i sempre ho ha estat. Però quan estava a la universitat, no tenia cap curs d'IA i mai vaig treballar en aquest camp. Així que el meu departament està especialitzat en un problema amb el qual no tinc res a veure. El consol és que el segon problema més important per al nostre departament és la programació paral·lela i multifils, és a dir, la meva especialització.
Виталий: Vas començar a treballar en Informàtica quan el camp de la programació multifils acabava de sorgir. La llista de les vostres publicacions mostra que els vostres primers treballs tractaven un ventall força ampli de temes: gestió de la memòria en sistemes multiprocés, sistemes de fitxers distribuïts, sistemes operatius. Per què tanta versatilitat? Heu intentat trobar el vostre lloc a la comunitat investigadora?
Michael: Com a estudiant, vaig participar a la Universitat de Wisconsin, on es va desenvolupar un dels primers sistemes operatius distribuïts. Allà vaig treballar juntament amb Rafael Finkel () i Marvin Solomon (). La meva tesi es va dedicar al desenvolupament d'un llenguatge per a programari de sistema per a sistemes distribuïts; ara tothom s'ha oblidat d'això, i gràcies a Déu. Vaig crear el llenguatge de programació Lynx, que tenia la intenció de facilitar la creació de servidors per a un sistema operatiu distribuït poc acoblat. Com que aleshores em dedicava principalment als sistemes operatius, vaig suposar que la meva carrera estaria principalment relacionada amb ells. Però Rochester era una universitat molt petita i, per això, els diferents grups van interactuar molt estretament entre ells. No hi havia una dotzena de persones amb sistemes operatius amb qui parlar, així que tots els meus contactes eren amb persones que treballaven en àrees completament diferents. Em va agradar molt, ser un polivalent és un gran avantatge per a mi. Si parlem específicament d'estructures de dades multifils i algorismes de sincronització, vaig començar a treballar-hi completament per casualitat.
Interfície coherent escalable IEEE, bloqueig MCS.
Виталий: Em pots explicar una mica més sobre això?
Michael: Aquesta és una història divertida que no em canso d'explicar a tothom. Va passar en una conferència a Boston, això va ser a finals dels 80 o principis dels 90. John Mellor-Crummey (), un graduat de la nostra facultat. El coneixia, però abans no havíem fet una investigació conjunta. Mary Vernon () de Wisconsin va fer una xerrada sobre un sistema multiprocessador que estaven desenvolupant a Wisconsin: . Aquest Multicube tenia un mecanisme de sincronització a nivell de maquinari anomenat Q on Sync Bit, i més tard es va canviar el nom de Q on Lock Bit perquè sonava com a formatge Colby, que era un joc de paraules. Si esteu interessats en els mecanismes multithreading, probablement sabeu que Colby es va convertir finalment en el motor de sincronització de l'estàndard d'interfície coherent escalable IEEE. Aquest era un mecanisme de bloqueig que creava punters d'una memòria cau a una altra a nivell de maquinari de manera que cada titular de bloqueig sabés de qui era el torn. Quan en John i jo vam saber parlar d'això, ens vam mirar i vam dir: per què ho fem a nivell de maquinari? No es pot aconseguir el mateix amb comparació i intercanvi? Vam agafar un dels quaderns estirat a l'aula i l'hem gargotat , mentre Mary continuava el seu informe. Posteriorment, el vam implementar, vam experimentar, la idea va tenir èxit i vam publicar l'article. En aquell moment, per a mi, aquest tema semblava només una distracció divertida, després de la qual vaig plantejar tornar als sistemes operatius. Però aleshores va sorgir un altre problema en la mateixa línia i, finalment, la sincronització, el multithreading i les estructures de dades es van convertir en la meva especialitat. Com podeu veure, tot va passar per casualitat.
Виталий: Fa temps que estic familiaritzat amb el bloqueig de MCS, però fins ara no sabia que era feina vostra, i no entenia que era un acrònim dels vostres cognoms.
Com sobreviure en un món en constant canvi?
Alex: Tinc una pregunta sobre un tema relacionat. Fa 30 o 40 anys hi havia més llibertat en diferents especialitats. Si vols iniciar una carrera en sistemes multithreading o distribuïts, estàs benvingut, si vols introduir-te en sistemes operatius, cap problema. A cada àrea hi havia moltes preguntes obertes i pocs experts. Ara han sorgit especialitzacions estretes: no només hi ha experts en sistemes operatius en general, hi ha especialistes en sistemes individuals. Passa el mateix amb els sistemes multithreading i distribuïts. Però el problema és que les nostres vides no són infinites; tothom només pot dedicar unes quantes dècades a la recerca. Com sobreviure en aquest nou món?
Michael: No som especials en aquest sentit, una vegada va passar el mateix en altres àmbits. Vaig tenir la sort d'haver començat a treballar en informàtica quan el camp estava en la seva "adolescència". Ja s'havien posat algunes bases, però tot era encara molt immadur. Aquesta oportunitat no es presenta sovint. L'enginyeria elèctrica ha existit des de fa molt de temps, la física encara més, les matemàtiques gairebé des del principi dels temps. Però això no vol dir que ningú ja no faci descobriments interessants en matemàtiques. Encara queden molts problemes oberts, però al mateix temps, cal aprendre més. Tens raó en assenyalar que ara hi ha moltes més especialitzacions que abans, però això només vol dir que ens trobem en la mateixa situació que la majoria de les altres àrees de l'activitat humana.
Alex: M'interessa l'aspecte més pràctic del tema aquí. Tinc formació en matemàtiques, i durant els meus estudis he assistit sovint a conferències i he treballat en diversos temes científics. Vaig descobrir que ningú de l'audiència entenia els meus informes i, de la mateixa manera, els informes d'altres persones només eren comprensibles per ells mateixos. No és el cas dels temes d'alt nivell, però tan bon punt comenceu a aprofundir en alguna cosa, el públic ja no pot seguir-vos el ritme. Com porteu això?
Michael: No sempre té èxit. Fa poc vaig preparar un informe en què vaig aprofundir massa en els detalls tècnics. A mesura que avançava la xerrada, va quedar clar que la majoria del públic no m'entenia, així que vaig haver d'adaptar-me a la situació sobre la marxa. Les diapositives no s'han pogut canviar, així que no ha sortit gaire bé, així que, en general, intento no utilitzar diapositives. En general, el meu consell és que tingueu en compte el vostre públic. Heu de saber amb qui parleu, quin és el seu nivell de coneixement i què han de escoltar per apreciar el vostre treball.
Виталий: Ens podríeu donar una pista de què va tractar aquesta conferència?
Michael: Per ser sincer, preferiria no ampliar aquest tema per tal de deixar l'anonimat de les persones en qüestió. La qüestió és que sovint ens aprofundim massa en les complexitats del problema en què estem treballant, de manera que ens resulta difícil explicar al principi de la xerrada per què el problema és interessant i important i com es relaciona amb els problemes que el públic ja ho sap. Segons les meves observacions, els estudiants tenen més dificultats per aprendre aquesta habilitat. I aquest també va ser el punt feble del meu informe recent. Un informe ben estructurat ha de trobar, des del primer moment, contacte amb l'audiència, explicar-li quin és exactament el problema i com es relaciona amb temes ja coneguts. La tècnica d'aquesta introducció depèn del públic. Si és completament variat, l'informe pot ser de diverses etapes. La introducció hauria de ser accessible per a tothom i, al final, és possible que la peça no us pugui seguir al dia, però persones relativament familiaritzades amb el vostre camp ho podran esbrinar.
Els estudiants es tornen més tontos? Tendències globals, internacionalització.
Alex: Heu estat observant estudiants durant diverses dècades. Els estudiants es tornen més tontos o intel·ligents de dècada en dècada o d'any en any? A Rússia, els professors es queixen constantment que els estudiants es tornen més tontos cada any, i realment no està clar què fer-hi.
Michael: Realment podeu escoltar molta negativitat de la nostra gent gran. Inconscientment, tenim la tendència a esperar que els estudiants absorbeixin tots els 30 anys d'experiència que ja tenim. Si tinc una comprensió més profunda que la que vaig fer l'any 1985, per què els estudiants no ho tenen? Segurament perquè tenen 20 anys, què en penseu? Crec que els canvis més significatius de les últimes dècades han estat en la composició demogràfica: ara tenim molt més estudiants internacionals, a excepció dels canadencs. Abans hi havia molts canadencs perquè estem molt a prop de la frontera canadenca i els estudiants d'allà poden viatjar a casa els caps de setmana. Però ara hi ha moltes bones universitats al Canadà, i els canadencs prefereixen estudiar aquí; molt menys d'elles arriben als EUA.
Alex: Creus que és una tendència local o global?
Michael: No recordo exactament qui, però algú va dir que el món és pla. El nostre àmbit s'ha tornat molt més internacional. Abans es feien exclusivament als Estats Units, després van decidir fer-los un cop cada 4 anys a altres països, i ara es fan a tot el món. Aquests canvis van afectar encara més , ja que sempre ha estat una organització més internacional que ACM. I hi ha càtedres de programes de la Xina, l'Índia, Rússia, Alemanya i molts altres països, perquè ara hi ha moltes coses a tot arreu.
Alex: Però, probablement, hi ha alguns aspectes negatius d'aquesta internacionalització?
Michael: Jo diria que tots els aspectes negatius no es relacionen amb la tecnologia, sinó amb la política. Hi havia una vegada, el principal problema era el fet que els EUA robaven la gent més intel·ligent i talentosa de països d'arreu del món. I ara el principal problema són els jocs polítics entre diferents països al voltant dels visats i la immigració.
Alex: És a dir, barreres i coses així. Està clar.
Vladimir: Personalment, m'interessa quin enfocament tens a l'hora d'ensenyar una assignatura nova als estudiants. Hi ha diferents opcions: pots intentar en primer lloc inspirar-los a provar alguna cosa nova, o pots prestar més atenció als detalls de com funciona una determinada tecnologia. Què prefereixes?
Treball eficaç amb els alumnes
Alex: I com trobar el maleït equilibri entre el primer i el segon?
Michael: El problema és que les classes no sempre van com m'agradaria. Acostumo a donar als alumnes material de lectura amb antelació perquè s'hi aprofundeixin, l'entenguin al màxim de les seves possibilitats i formulin preguntes sobre aquelles parts que no han pogut entendre. Després, a classe, podeu centrar-vos en els moments més difícils i explorar-los junts. Així és com m'agrada més donar classes. Però tenint en compte la càrrega que ara recau sobre els estudiants, no sempre puc assegurar-me que es preparen amb antelació. Com a resultat, haureu de dedicar molt més temps a la narració general del material del que us agradaria. Malgrat això, intento mantenir les nostres classes interactives. En cas contrari, serà més fàcil gravar un vídeo una vegada que els estudiants puguin veure'l a casa. El punt de les classes en directe és la interacció humana. A classe, prefereixo fer servir guix i una pissarra en lloc de diapositives, excepte en alguns casos en què un diagrama és massa complex per representar-lo a la pissarra. Gràcies a això, no he de seguir un pla de lliçons rígid. Com que no hi ha un ordre estricte en què dono el material, em permet adaptar-lo al públic en funció de les preguntes que rebo. En general, intento que les classes siguin el més interactives possible, de manera que el material que presento depengui de les preguntes que se'm facin.
Vladimir: És genial. Segons la meva experiència, és bastant difícil aconseguir que els oients facin preguntes. Fins i tot si demaneu per endavant per fer qualsevol pregunta, per molt estúpid o intel·ligent, segueixen callats. Com porteu això?
Michael: Riuràs, però si et quedes prou en silenci, tard o d'hora tothom es sentirà incòmode i algú farà una pregunta. O podeu fer una pregunta tècnica senzilla amb una resposta sí o no per determinar si la gent entén el que s'acaba de dir. Per exemple, hi ha una cursa de dades a l'exemple anterior? Qui ho pensa? Qui pensa que no? Qui no entén res, perquè en total només s'han pujat la meitat de les mans?
Виталий: I si has contestat malament, ets expulsat de la classe :)
Michael: Si no has respost res, hauries de fer una pregunta. He d'entendre què ha de saber exactament l'alumne per respondre la pregunta que acabo de fer. Necessito que m'ajudin a ajudar-los. Estic disposat a adaptar-me a ells perquè entenguin el problema. Però si no sé què els passa pel cap, no ho puc fer. I si no doneu pau als alumnes durant molt de temps, de vegades al final fan les preguntes correctes, és a dir, les que em permeten veure què passa exactament al cap dels alumnes.
Alex: De vegades aquestes preguntes porten a idees que no havíeu pensat abans? Són inesperats? Et permeten mirar un problema amb una nova llum?
Michael: Hi ha preguntes que obren una nova manera de presentar el material. Sovint hi ha preguntes que porten a problemes interessants dels quals no pensava parlar. Els estudiants sovint em diuen que tinc tendència a sortir del tema quan això passa. I, segons ells, molt sovint aquesta és la part més interessant de la lliçó. Molt poques vegades, només unes poques vegades, els estudiants van fer preguntes que van impulsar una nova direcció en la recerca i es van convertir en un article. Això passa molt més sovint en les converses amb els estudiants que no pas durant les classes, però de vegades passava durant les classes.
Alex: Així que els estudiants us van fer preguntes sobre la base de les quals va ser possible publicar un article?
Michael: Sí.
Виталий: Amb quina freqüència tens aquestes converses amb els alumnes? Quan volen aprendre més del que es va tractar durant la lliçó?
Michael: Amb els meus estudiants de postgrau - tot el temps. En tinc uns 5 o 6, i discutim alguna cosa amb ells tot el temps. I converses d'aquest tipus amb alumnes que simplement assisteixen a les meves classes no són gaire habituals. Encara que m'agradaria que això passés més sovint. Sospito que simplement tenen por de venir a la facultat durant l'horari d'oficina. Cada semestre, alguns alumnes aconsegueixen superar aquesta barrera psicològica, i sempre és molt interessant parlar amb ells després de classe. És cert que si tots els alumnes fossin tan valents, simplement no tindria prou temps. Així que potser tot funciona com hauria de ser.
Виталий: Com aconsegueixes trobar temps per comunicar-te amb els alumnes? Pel que jo sé, als EUA els professors tenen molta feina: sol·licitar beques i similars.
Michael: Sincerament, treballar amb estudiants és l'aspecte de la meva feina que més m'agrada. Així que tinc prou motivació per això. La major part del temps que passo al meu despatx el dedico a reunions de tot tipus. Ara és estiu, així que la meva agenda és menys ocupada, però durant el curs escolar, cada dia de 9 a 17 ho tinc tot ple. Treballs de recerca, revisions, subvencions: per a tot això només hi ha vespres i caps de setmana.
Com estar al dia amb la preparació de nous cursos i llibres.
Alex: Actualment, continueu impartint algun curs que fa temps que imparteu? Una cosa així com una introducció a la informàtica.
Michael: El primer que em ve al cap aquí és un curs de llenguatges de programació.
Alex: Què tan diferent és la versió actual d'aquest curs de la que era fa 10, 20, 30 anys? Potser el que és més interessant aquí no són els detalls d'un curs en particular, sinó les tendències generals.
Michael: El meu curs de llenguatges de programació era una mica inusual en el moment en què el vaig crear. Vaig començar a llegir-lo a finals de la dècada de 1980, en substitució del meu col·lega Doug Baldwin (). El tema del curs només estava tangencialment relacionat amb la meva especialitat, però quan va marxar, jo era el millor candidat per impartir el curs. No m'agradava cap dels llibres de text que hi havia en aquell moment, així que vaig acabar escrivint jo mateix el llibre de text d'aquest curs. (Nota de l'editor: estem parlant del llibre) Ara s'utilitza en més de 200 universitats d'arreu del món. El meu enfocament és inusual perquè barreja deliberadament els problemes del disseny i la implementació del llenguatge, i presta molta atenció a la interacció entre aquests aspectes en totes les àrees possibles. L'enfocament bàsic s'ha mantingut sense canvis, igual que molts conceptes bàsics: abstraccions, espais de noms, modularitat, tipus. Però el conjunt de llenguatges amb què es demostren aquests conceptes ha canviat completament. Quan es va crear el curs, hi havia molts exemples en Pascal, però avui molts dels meus alumnes ni tan sols han sentit parlar d'aquesta llengua. Però coneixen Swift, Go, Rust, així que he de parlar dels idiomes que s'utilitzen avui dia. A més, els estudiants ara estan ben versats en llenguatges de script, però quan vaig començar a impartir aquest curs, es tractava de llenguatges compilats. Ara necessitem molt material sobre Python, Ruby i fins i tot Perl, perquè això és el que s'escriu el codi en aquests dies, i hi ha moltes coses interessants passant en aquests llenguatges, inclòs en el camp del disseny de llenguatge.
Виталий: Aleshores, la meva següent pregunta estarà relacionada amb l'anterior. Com mantenir-se al dia en aquest àmbit? Sospito que actualitzar un curs com aquest requereix molta feina: cal entendre nous idiomes, entendre les idees principals. Com ho fas?
Michael: No puc presumir que sempre ho tinc al 100%. Però la majoria de vegades només faig el que fan els altres: llegir Internet. Si vull entendre Rust, ho faig a Google, vaig a la pàgina de Mozilla i llegeixo el manual que hi ha publicat. Això és part de les coses que passen en el desenvolupament comercial. Si parlem de ciència, cal seguir els informes de les conferències principals.
Vincle entre l'empresa i l'acadèmia
Виталий: Parlem de la connexió entre l'empresa i la recerca científica. A la vostra llista de treballs, he trobat diversos articles sobre la coherència de la memòria cau. Entenc que els algorismes de consistència de la memòria cau eren inestables en el moment en què es van publicar? O no prou estès. Què tan comunes eren les teves idees a la pràctica?
Michael: No estic exactament segur de quines publicacions parleu. He treballat bastant amb els meus alumnes Bill Bolosky () i Leonidas Kontotanassis () a principis de la dècada de 1990 sobre la gestió de la memòria de les màquines Neumann. En aquell moment, les empreses encara no tenien una comprensió de com fer correctament un sistema multiprocessador: val la pena crear suport per accedir a la memòria remota a nivell de maquinari, val la pena distribuir la memòria, és possible carregar la memòria cau des? memòria remota, o és necessari moure pàgines al sistema del quiròfan? Bill i Leonidas van treballar en aquesta àrea i van explorar enfocaments sense càrrega remota de memòria cau. Això no estava directament relacionat amb la coherència de la memòria cau, però encara era treball en la gestió de la memòria NUMA i, posteriorment, els enfocaments moderns per a la col·locació de pàgines en sistemes operatius moderns van créixer a partir d'això. En general, Bill i Leonidas van fer un treball important, encara que no va ser el més influent en aquesta àrea: hi havia moltes altres persones que treballaven en el mateix en aquell moment. Més tard, vaig treballar en un tema relacionat amb la coherència de la memòria cau en el context de la memòria transaccional de maquinari. El grup amb el qual vaig treballar en aquest problema va acabar rebent diverses patents. Hi ha idees força interessants darrere d'ells, però no crec que s'acabin implementant a la pràctica. D'una manera o altra, em costa jutjar la seva rendibilitat.
Alex: En aquest sentit, una pregunta més personal: quina importància té per a tu que les teves idees es posin en pràctica? O no t'ho penses?
Michael: M'encanta fer aquesta pregunta en entrevistes amb altres persones, candidats o candidats que vulguin incorporar-se a la facultat. No crec que hi hagi una resposta correcta a aquesta pregunta. Les persones que fan coses interessants poden tenir motivacions molt diferents. M'atreuen els problemes perquè personalment els trobo interessants, no pels seus beneficis pràctics. Però d'altra banda, quan alguna cosa interessant encara troba aplicació, m'agrada molt. Així que aquí no és fàcil. Però al començament del meu treball, encara no em mou la idea d'un ús final al món, sinó l'harmonia de la idea i el desig d'explorar-la i veure què en surt. Si al final dóna resultats pràctics, genial.
Alex: A causa de la vostra educació i experiència, sou més capaç que la majoria de jutjar el valor de les idees d'altres persones. Podeu comparar-los i determinar quin funciona millor amb quin. Estic segur que teniu una opinió sobre coses que actualment estan sent utilitzades a la pràctica per grans fabricants com Intel. Des del vostre punt de vista, fins a quin punt és correcte el rumb que estan fent aquestes empreses?
Michael: La pràctica sempre gira al voltant del que pot tenir èxit comercial, és a dir, generar beneficis, i és millor que ho preguntis a algú més. El meu treball dóna lloc principalment a publicacions, i en l'àmbit dels sistemes operatius s'avaluen en funció d'indicadors de rendiment: velocitat, consum d'energia, mida del codi. Però sempre m'ha semblat que aquests resultats empírics s'afegeixen als articles només perquè es publiquin, i els motius reals de la gent per treballar són estètics. Els investigadors avaluen les solucions des d'una perspectiva artística, es preocupen per l'elegància de les idees i intenten crear alguna cosa millor que els enfocaments existents. Els investigadors estan impulsats per motius personals, subjectius i estètics. Però no podeu escriure sobre això a l'article en si; aquestes coses no són arguments per al comitè del programa. Afortunadament, les solucions elegants sovint també són ràpides i barates. Una dotzena de companys i jo vam parlar d'aquest tema fa uns 15 anys i vam acabar escrivint un article al respecte. Crec que encara el pots trobar ara, es diu o alguna cosa així, té més d'una dotzena d'autors. Aquest és l'únic article del qual sóc l'autor juntament amb , així que si cerqueu el seu nom a la meva llista de publicacions, trobareu el que necessiteu. Parla de l'avaluació de la investigació de sistemes i de la importància de l'elegància.
Alex: Per tant, hi ha una diferència entre l'estàndard del que es considera bo en ciència i en negocis. La ciència avalua el rendiment, el consum d'energia, el TDP, la facilitat d'implementació i molt més. Tens l'oportunitat de fer aquest tipus de recerca a la universitat? Tens un laboratori amb diferents màquines i diferents arquitectures on puguis fer experiments?
Michael: Sí, el nostre departament té moltes màquines interessants diferents. Molt sovint són petits, tenim un petit clúster i molts sistemes multiprocessador amb diferents acceleradors. A més, el campus té un enorme centre d'informàtica que dóna servei a científics de diverses desenes de disciplines diferents. Té uns mil nodes i vint mil nuclis, tots a Linux. Si sorgeix la necessitat, sempre podeu comprar algun AWS. Per tant, no tenim restriccions significatives amb el maquinari.
Alex: Com era fa trenta anys? Hi va haver problemes llavors?
Michael: Aleshores era una mica diferent. A mitjans i finals de la dècada de 1980, es considerava que la ciència mancava de recursos informàtics. Per posar remei a aquesta situació, la National Science Foundation ) va crear un programa de recerca experimental coordinada (Coordinated Experimental Research, CER). La missió del programa era proporcionar infraestructura informàtica per als departaments d'informàtica, i ha aconseguit un canvi significatiu. Amb els diners que va aportar, nosaltres a la Universitat de Rochester vam comprar una papallona BBN de 1984 nusos el 128, això va ser un any abans que jo hi arribés. En aquell moment era el sistema multiprocessador més gran del món amb memòria compartida. Tenia 128 processadors, cadascun en una placa base independent, i ocupava quatre bastidors. Cada processador tenia un megabyte de memòria, 128 megabytes de memòria RAM era una quantitat inimaginable en aquell moment. En aquesta màquina hem implementat el bloqueig MCS per primera vegada.
Alex: Aleshores, si us entenc correctament, de moment s'ha resolt el problema amb el maquinari?
Michael: En general, sí. Hi ha algunes advertències: primer, si estàs fent arquitectura d'ordinadors a nivell de xip, és difícil de fer en un entorn acadèmic perquè hi ha eines molt millors per fer-ho en els negocis. Si necessiteu quelcom de menys de 10 nanòmetres, haureu de demanar-lo a una altra persona. En aquesta àrea és molt més fàcil ser investigador a Intel. Si estàs treballant en comunicacions òptiques en xips o en memòria d'estat sòlid, trobaràs tecnologies en els negocis que encara no són de la ciència, així que has de crear aliances. Per exemple, Stephen Swanson () creat per a les noves tecnologies de memòria. Aquest formulari no sempre funciona, però en alguns casos pot tenir bastant èxit. A més, en ciència el desenvolupament dels sistemes informàtics més potents és més difícil. Els projectes de supercomputadors més grans que es troben actualment als Estats Units, el Japó i la Xina estan centrats en els negocis.
Aplicació pràctica d'idees. MCS, MS, CLH, JSR 166, treballant amb Doug Lee i molt més.
Виталий: Ja heu parlat de com vau començar a treballar en algorismes de sincronització. Tens dos articles molt famosos sobre и , que en certa manera es van implementar a Java. (Nota de l'editor: es poden veure totes les publicacions ). Allà es va implementar aquest bloqueig amb alguns canvis i va resultar , i la cua s'ha implementat tal com estava previst. Però van passar molts anys entre la publicació dels vostres articles i la seva aplicació pràctica.
Alex: Sembla uns 10 anys en el cas de la cua.
Michael: Abans que aquestes característiques apareguessin a la biblioteca estàndard de Java?
Виталий: Sí. Què vas fer perquè això succeís? O no van fer res?
Michael: Puc explicar-vos com MS Queue va entrar a Java 5. Uns anys abans de sortir, vaig treballar amb el grup de Mark Moyers a Sun Microsystems al seu laboratori prop de Boston. Va organitzar un taller per a persones que coneixia que treballaven en problemes interessants en multithreading perquè volia trobar temes que pogués vendre a la seva empresa. Allà va ser on vaig conèixer la Doug Lea. Doug i jo i unes 25 persones més de Sun vam estar discutint junts la presentació de Doug , que més tard esdevingué java.util.concurrent. Durant el camí, Doug va dir que li agradaria utilitzar la cua MS, però per això necessitava un comptador per al nombre d'elements de la cua per a la interfície. És a dir, això s'hauria d'haver fet per un mètode separat, atòmic, precís i ràpid. Vaig suggerir simplement afegir números de sèrie als nodes, agafar el número del primer node i l'últim i restar un de l'altre. En Doug es va rascar el cap, va dir "per què no" i va acabar fent això. Vam parlar de la implementació d'aquest enfocament a la biblioteca, però Doug va fer la major part del treball ell mateix. Com a resultat, va aconseguir establir un excel·lent suport multithreading a Java.
Alex: Per tant, si entenc correctament, el mètode .size() hauria d'haver format part de la interfície estàndard de la cua i hauria d'haver tingut una complexitat algorítmica d'O(1)?
Michael: Sí, i a més d'això, cal un comptador a part.
Alex: Perquè si truqueu al mètode .size() a Java, s'espera que el resultat estigui disponible immediatament i no es basa en la mida real de la col·lecció. Ja veig, gràcies.
Michael: Uns anys més tard estava treballant en estructures de dades duals amb el meu alumne Bill Scherer; de fet, d'això parlaré. . En Doug va venir a nosaltres i ens va dir que podria utilitzar-los al Java Executor Framework. Juntament amb Bill, van crear dues implementacions, les anomenades cues justes i injustes. Els vaig assessorar en aquest projecte, tot i que no vaig participar en l'escriptura del codi real. Com a resultat, la velocitat dels executors ha augmentat significativament.
Vladimir: us heu trobat amb implementacions incorrectes dels vostres algorismes o sol·licituds per afegir funcions noves? En general, la pràctica hauria de coincidir amb la teoria, però sovint difereixen. Suposem que heu escrit un algorisme i, sobre el paper, funciona, però les persones que estan involucrades en la implementació van començar a demanar-vos més funcions o algun tipus d'ajustament de l'algorisme. Has tingut mai aquestes situacions?
Michael: L'únic exemple en què algú va venir a mi i em va preguntar "com implementar-ho" va ser la pregunta de Doug, de la qual ja vaig parlar. Però hi ha hagut alguns casos en què s'han fet canvis interessants per adaptar-se a les necessitats pràctiques. Per exemple, l'equip K42 d'IBM va convertir el bloqueig MCS i el va convertir en una interfície estàndard, de manera que no calia passar el node de la cua d'anada i tornada a les rutines d'adquisició i llançament. Gràcies a aquesta interfície estàndard, una idea que era bonica en teoria va començar a funcionar a la pràctica. Sorprèn que mai no publiquessin cap article al respecte i, tot i que van rebre una patent, després la van abandonar. La idea era meravellosa, i intento parlar-ne sempre que sigui possible.
Hi ha hagut altres casos en què la gent ha fet millores als algorismes que he publicat. Per exemple, la cua MS té un mecanisme d'instal·lació de dos passos, el que significava que hi havia dos CAS al camí crític de la cua. En els cotxes més antics, els CAS eren bastant cars. Intel i altres fabricants els han optimitzat bastant bé recentment, però una vegada eren instruccions de 30 cicles, per la qual cosa no era desitjable tenir-ne més d'un en el camí crític. Com a resultat, es va desenvolupar una cua diferent que era similar a la cua MS, però que només tenia una operació atòmica al camí crític. Això es va aconseguir a causa del fet que durant un cert període de temps l'operació podia trigar O(n) temps, en lloc de O(1). Era improbable, però possible. Això va passar pel fet que en determinats moments l'algoritme va recórrer la cua des del principi fins a la posició actual d'aquesta cua. En general, l'algoritme va tenir molt èxit. Pel que jo sé, no és molt utilitzat, en part perquè les operacions atòmiques requereixen molt menys recursos que abans. Però la idea era genial. També m'agrada molt el treball de Dave Dice d'Oracle. Tot el que fa és molt pràctic i utilitza el ferro de manera molt intel·ligent. Va tenir una mà en bona part dels algorismes de sincronització i estructures de dades multifils conscients de NUMA.
Vladimir: Quan escriviu algorismes o ensenyeu als estudiants, el resultat del vostre treball no és visible immediatament. La comunitat necessita un temps per familiaritzar-se amb, per exemple, un article nou. El nou algorisme no troba aplicació immediatament.
Michael: No és tan clar si l'article serà significatiu o no. Crec que seria interessant fer un estudi de comunicacions que han guanyat premis en congressos. És a dir, mira els articles que la gent dels comitès del programa en un moment considerava els millors. Heu d'intentar calcular pel nombre d'enllaços i l'impacte en els negocis fins a quin punt van resultar realment influents aquests articles en 10, 20, 25 anys. Dubto que hi hagi una forta correlació entre tots dos. No serà zero, però molt probablement serà molt més feble del que voldríem. Moltes idees romanen sense reclamar durant molt de temps abans que es generalitzin. Per exemple, prenem la memòria transaccional. Van passar més de 10 anys des que es va publicar l'article original fins que la gent va començar a construir màquines amb ell. I abans de l'aparició d'aquesta memòria als productes comercials, i els 20. Durant molt de temps ningú va prestar atenció a l'article, i després el nombre d'enllaços a ell va augmentar considerablement. Seria difícil predir-ho amb antelació. D'altra banda, de vegades les idees troben implementació immediata. Fa uns anys, vaig escriure un article amb Joe Izraelevitz per a DISC que proposava una nova definició formal de validesa per a estructures de dades persistents que es podrien utilitzar després que l'ordinador que les executava s'estavellava. Em va agradar l'article des del principi, però va resultar ser molt més popular del que m'esperava. Va ser utilitzat per diversos grups diferents i finalment es va convertir en la definició estàndard d'estructures de persistència. La qual cosa, per descomptat, és agradable.
Vladimir: Hi ha alguna tècnica que utilitzeu per a l'avaluació? Fins i tot intentes avaluar els teus articles i els teus estudiants? Pel que fa a si la persona que vas ensenyar va en la direcció correcta.
Michael: Com tothom, presto més atenció al que estic fent en aquest moment. De nou, com tothom, de tant en tant comprovo Google Acadèmic per veure si s'estan citant els meus articles anteriors, però això és més per curiositat. Sobretot estic absorbit pel que estan fent els meus alumnes ara. Quan es tracta d'avaluar el treball actual, part d'això són consideracions estètiques, què és elegant i què no. I a nivell quotidià, les preguntes obertes tenen un paper important. Per exemple, un estudiant em ve amb un gràfic d'alguns resultats i estem intentant entendre d'on prové algun comportament estrany del gràfic. En general, en el nostre treball estem constantment intentant entendre coses que encara no entenem.
Memòria transaccional
Виталий: Potser podem parlar una mica de memòria transaccional?
Michael: Crec que val la pena dir-ho almenys una mica perquè hi he posat molt d'esforç. Aquest és un tema sobre el qual tinc més publicacions que cap altre. Però al mateix temps, curiosament, sempre vaig ser molt escèptic sobre la memòria transaccional. En la meva opinió, (M. Herlihy, J. E. B. Moss) es va publicar abans del seu temps. A principis de la dècada de 1990, van suggerir que la memòria transaccional podria ajudar els programadors talentosos a treballar en estructures de dades multifils, de manera que aquestes estructures poguessin ser utilitzades com a biblioteques pels programadors normals. És a dir, seria una ajuda per a Doug Lee fent el seu JSR 166. Però la memòria transaccional no estava pensada per facilitar la programació multiprocés. Però això és exactament com es va començar a percebre a principis dels anys 2000, quan es va generalitzar. Es va anunciar com una manera de resoldre el problema de la programació paral·lela. Aquest enfocament sempre m'ha semblat sense esperança. La memòria transaccional només podria facilitar l'escriptura d'estructures de dades paral·leles. Això, em sembla, és el que va aconseguir.
Sobre la dificultat d'escriure codi multifils
Alex: Molt interessant. Sembla que hi ha una certa barrera entre els programadors habituals i els que poden escriure codi multifils. L'any passat, vaig parlar diverses vegades amb persones que estaven implementant algun marc algorítmic. Per exemple, amb Martin Thomson, així com amb programadors que treballen en biblioteques multifils. (Nota de l'editor: Martin Thompson és un desenvolupador molt famós, va escriure и . I també ho té a la nostra conferència Joker 2015, gravació de vídeo . Ell és el mateix aquesta conferència també disponible). El principal repte, diuen, és fer que els algorismes siguin ràpids i fàcils d'utilitzar. És a dir, intenten superar aquesta barrera i atraure el màxim de gent possible cap a aquesta zona. Què en penses?
Michael: Aquest és el principal problema del multithreading: com aconseguir un alt rendiment sense augmentar la complexitat del sistema.
Alex: Perquè quan intenten evitar la complexitat, l'algoritme es torna menys universal.
Michael: La clau aquí són les abstraccions dissenyades correctament. Em sembla que això és generalment el principal per als sistemes informàtics com a camp. A Butler Lampson li agrada fer servir aquest terme i ens anomena "comerciants d'abstraccions". Les tecnologies simples no existeixen avui dia. Els processadors que utilitzem tenen 10 milions de transistors; la senzillesa està fora de dubte. Al mateix temps, l'ISA és molt més senzill que el processador, ja que hem treballat durant molt de temps per oferir-li un alt rendiment i una interfície relativament senzilla. Però tampoc tot va bé amb ella. El mateix problema passa amb els acceleradors que ara estan apareixent al mercat. Es plantegen preguntes: com fer la interfície adequada per a la GPU, un mecanisme de xifratge, compressió, un mecanisme de transcodificació, un mecanisme d'àlgebra lineal o fins i tot un FPGA més flexible. Com crear una interfície que faci que l'eina sigui fàcil d'utilitzar i amagui la complexitat? No se'n desferrà, sinó que l'amagarà a un simple programador.
Alex: Tal com ho entenc, encara tenim una barrera per entendre les abstraccions. Prenem el model de memòria; en la nostra etapa de desenvolupament de la ciència i la tecnologia, aquesta és una de les principals abstraccions. Gràcies a això, tots els programadors es divideixen en dos grups: la part més gran són els que no ho entenen, i la part més petita són els que entenen, o pensen que entenen.
Michael: Aquesta és una bona pregunta: algú de nosaltres entén realment el model de memòria?
Виталий: Especialment en C++.
Michael: Parleu amb Hans Boehm alguna vegada. És una de les persones més intel·ligents que conec, un dels principals experts en models de memòria. De seguida et dirà que hi ha moltes coses que no entén. Però si tornem al tema de les abstraccions, aleshores, al meu entendre, es va expressar la idea més important en el camp dels models de memòria durant els darrers 30 anys. . (Nota de l'editor: hi ha disponible una llista completa de publicacions ).
Alex: La meva pregunta és: aquesta barrera prové de la naturalesa mateixa del concepte?
Michael: No. Sarita va arribar a la conclusió que amb l'enfocament adequat, podeu ocultar amb èxit tota la complexitat, obtenir un alt rendiment i oferir al programador una API senzilla. I si seguiu aquesta API, podeu aconseguir una coherència constant. Crec que aquest és el model adequat. Escriviu codi sense curses de dades i obteniu consistència seqüencial. Per descomptat, per reduir la probabilitat de competir, es necessiten eines especials, però això és una altra qüestió.
Vladimir: Hi ha hagut moments a la teva carrera en què un problema que semblava resolt es va convertir de sobte en una catàstrofe, o va resultar que aquest problema no era solucionable? Per exemple, en teoria podeu factoritzar qualsevol nombre o determinar si qualsevol nombre és primer. Però a la pràctica això pot ser difícil de fer; amb el maquinari actual és difícil factoritzar els números. T'ha passat alguna cosa semblant?
Michael: De seguida no recordo res semblant. Hi ha hagut moments en què em va semblar que no quedava res a fer en una zona determinada, però llavors hi va passar una cosa nova i interessant. Per exemple, vaig pensar que l'àrea de cua il·limitada ja havia arribat a la maduresa. Després de diverses millores a la cua MNS, ja no va passar res. I després Morrison (Adam Morrison) i Afek (Yehuda Afek) van inventar . Va quedar clar que era possible una cua multifils il·limitada, on la majoria de vegades només hi havia una instrucció d'obtenció i increment al camí crític. I això va permetre aconseguir un ordre de magnitud millor rendiment. No és que no sabem que la recuperació i l'increment és una cosa molt útil. Eric Freudenthal va escriure sobre això al seu treball a l'Ultracomputador amb Allan Gottlieb a finals dels anys vuitanta, però es tractava de cues limitades. Morrison i Afek van poder utilitzar la recuperació i l'increment en una cua il·limitada.
Noves arquitectures. La victòria de la memòria transaccional està a prop?
Vladimir: Esteu buscant noves solucions arquitectòniques que puguin ser útils per als algorismes?
Michael: Per descomptat, hi ha moltes coses que m'agradaria veure implementades.
Vladimir: De quin tipus, per exemple?
Michael: En primer lloc, unes senzilles extensions de la nostra memòria transaccional a nivell de maquinari als processadors Intel i IBM. En particular, m'agradaria que la càrrega i la botiga no transaccionals que s'acaben de produir estiguin disponibles immediatament dins de les transaccions. Immediatament condueixen a bucles en la seqüència passa abans, de manera que poden ser difícils. Però si manteniu capes d'abstracció, hi ha moltes coses molt interessants que podeu fer fora de la transacció mentre es produeix. No sé com de difícil seria implementar això, però seria molt útil.
Una altra cosa útil és carregar la memòria cau des de la memòria remota. Crec que tard o d'hora això es farà. Aquesta tecnologia permetrà la creació de sistemes amb memòria desagregada. Seria possible mantenir, per exemple, 100 terabytes de memòria no volàtil en un bastidor, i el propi sistema operatiu decidiria dinàmicament quines seccions d'aquesta memòria haurien de correspondre a l'espai d'adreces física dels processadors. Això seria molt útil per a la computació en núvol, ja que permetria proporcionar grans quantitats de memòria a les tasques que ho necessiten. Crec que algú ho farà.
Виталий: Per acabar de parlar de la memòria transaccional, tinc una pregunta més sobre aquest tema. La memòria transaccional substituirà finalment les estructures de dades multifils estàndard?
Michael: No. Les transaccions són un mecanisme especulatiu. A nivell de programació són panys atòmics, però per dins són especulacions. Aquesta predicció funciona si la majoria de les suposicions són correctes. Per tant, la memòria transaccional funciona bé quan els fils gairebé no interactuen entre ells, i només cal assegurar-se que no hi hagi interaccions. Però si comença un missatge entre fils, les transaccions serveixen de poc. Deixeu-me explicar, estem parlant del cas en què les transaccions s'emboliquen al voltant de tota l'operació atòmica. Encara es poden utilitzar amb èxit com a components per a estructures de dades multifils. Per exemple, si necessiteu un CAS de tres paraules i heu de multifilar tres coses petites al mig d'un algorisme realment multifil que funciona amb vint fils alhora. En general, les transaccions poden ser útils, però no eliminaran la necessitat de dissenyar correctament estructures de dades multifils.
Memòria no volàtil, DIMM Optane, dispositius ultra ràpids.
Виталий: L'últim que m'agradaria parlar és el tema de la vostra investigació actual: la memòria no volàtil. Què podem esperar en aquest àmbit en un futur proper? Potser coneixeu alguna implementació efectiva que ja existeixi?
Michael: No sóc un expert en maquinari, només sé el que llegeixo a les notícies i el que em diuen els meus companys. Tothom ja ha sentit que Intel ven , que tenen aproximadament 3 vegades la latència de lectura i 10 vegades la latència d'escriptura que la RAM dinàmica. Aviat estaran disponibles en versions de molt gran volum. És curiós pensar que podríeu tenir un ordinador portàtil amb diversos terabytes de RAM adreçable per bytes. És probable que d'aquí a 10 anys decidim utilitzar aquesta nova tecnologia, ja que utilitzem DRAM, només augmentar el volum. Però gràcies a la independència energètica se'ns obren oportunitats completament noves. Podem canviar fonamentalment la pila d'emmagatzematge de manera que no hi hagi una separació entre la memòria de treball adreçable per bytes i la memòria persistent estructurada en blocs. Per tant, no haurem de serialitzar tot el que cal transferir d'un programa executat a un altre a fitxers estructurats en blocs. D'això podem derivar molts principis importants que afecten els sistemes operatius, els entorns d'execució i els magatzems de dades distribuïts. Aquesta àrea és molt interessant per treballar. Personalment, em costa predir a què comportarà tot això, però els problemes aquí són extremadament entretinguts. Pot haver-hi canvis revolucionaris aquí, i segueixen amb molta naturalitat el treball sobre multithreading, ja que la recuperació d'errors és un procés de "multithreading" al costat del funcionament normal del sistema.
El segon tema principal en què estic treballant actualment és la gestió de dispositius ultra ràpids i l'accés segur als dispositius des de l'espai d'usuari amb control de polítiques sistèmiques. En els últims anys, hi ha hagut una tendència a traslladar l'accés al dispositiu a l'espai d'usuari. Això es fa perquè la pila del nucli TCP-IP no pot funcionar a la part superior d'una interfície de xarxa que necessita un paquet nou cada 5 microsegons; simplement no es mantindrà. Per tant, els fabricants ofereixen accés directe als dispositius. Però això significa que el sistema operatiu perd el control del procés i no pot proporcionar un accés adequat al dispositiu per a les aplicacions de la competència. El nostre equip d'investigació creu que aquesta mancança es pot evitar. Aquest mes tindrem un article sobre això a USENIX ATC. Està relacionat amb el treball sobre la persistència, ja que la memòria persistent adreçable per bytes de llarga durada és, en essència, un dispositiu amb E/S ultra ràpida al qual cal accedir a l'espai d'usuari. Aquesta investigació fa possibles nous enfocaments als micronuclis, exokernels i altres intents tradicionals de traslladar de manera segura la funcionalitat del nucli del sistema operatiu a l'espai d'usuari.
Vladimir: La memòria adreçable per bytes és fantàstica, però hi ha una limitació física: la velocitat de la llum. Això vol dir que inevitablement hi haurà un retard en interactuar amb el dispositiu.
Michael: Tota la raó.
Vladimir: Hi haurà prou capacitat per fer front a les noves càrregues?
Michael: Aquesta és una pregunta excel·lent, però em costarà respondre. La idea de processar en memòria fa temps que existeix, és molt interessant, però també molt complexa. No he treballat en aquest àmbit, però seria fantàstic que s'hi fessin alguns descobriments. Em temo que no tinc res més a afegir.
Vladimir: Hi ha un problema més. Les quantitats noves i significativament més grans de RAM seran impossibles d'encaixar a la CPU. Per tant, per limitacions físiques, aquesta memòria RAM ha d'estar aïllada.
Michael: Tot depèn del nombre de defectes en la producció de circuits integrats. Si fos possible crear hòsties de semiconductors completament sense defectes, seria possible fer-ne un microcircuit sencer. Però ara no sabem com fer microcircuits més grans que els segells de correus.
Vladimir: Però encara estem parlant de mides enormes, d'uns centímetres. Això, inevitablement, té un impacte en la latència.
Michael: Sí. No pots fer res amb la velocitat de la llum.
Vladimir: Malauradament.
La propera gran tendència. Estructures de dades duals. Hidra.
Виталий: Pel que entenc, captes les noves tendències molt ràpidament. Vas ser un dels primers a treballar en memòria transaccional i un dels primers a treballar en memòria no volàtil. Quina creus que serà la propera gran tendència? O potser és un secret?
Michael: Per ser sincer, no ho sé. Espero poder notar quan surti alguna cosa nova. No he tingut la sort d'inventar cap camp nou pel meu compte, però he tingut una mica de sort i he pogut començar a treballar força aviat en camps nous creats per altres. Espero poder fer-ho en el futur.
Alex: L'última pregunta d'aquesta entrevista serà sobre la teva actuació a Hydra i les teves activitats a l'escola. Si ho entenc bé, l'informe a l'escola tractarà sobre algorismes lliures de bloqueig, i a la conferència sobre estructures de dades dobles. Podries dir algunes paraules sobre aquests informes?
Michael: En part, ja hem tractat aquests temes amb vosaltres en aquesta entrevista. Es tracta del treball que vaig fer amb el meu alumne Bill Scherer. Va escriure una tesi sobre ella, i Doug Lee també hi va contribuir, i finalment es va convertir en part de les cues sincròniques multifils de la biblioteca Java. Suposem que l'estructura de dades es llegeix i s'escriu sense bloquejar, és a dir, cada operació té un nombre limitat d'instruccions en el camí crític. Si intenteu eliminar dades d'un contenidor buit, o intenteu eliminar determinades dades que no es troben en aquest contenidor, se us informarà immediatament que això no es pot fer. Però aquest comportament pot no ser acceptable si el fil realment necessita aquestes dades. Aleshores, el primer que em ve al cap és crear un bucle que preguntarà constantment si han aparegut les dades necessàries. Però després hi ha interferències per a tots els altres. A més, amb aquest enfocament, podeu esperar 10 minuts, i després arribarà algun altre fil i, accidentalment, rebrà primer les dades necessàries. Les estructures de dades duals encara no tenen bloqueig, però permeten que els fils esperen correctament. El terme "doble" significa que l'estructura conté dades o sol·licituds de dades, anomenem-les antidades. Per tant, si intenteu recuperar alguna cosa d'un contenidor buit, es posarà una sol·licitud al contenidor. Ara el fil pot esperar una sol·licitud sense molestar ningú més. A més, l'estructura de dades assigna prioritats a les sol·licituds perquè, quan es rebin, les transmeti a la persona adequada. El resultat és un mecanisme sense bloqueig que encara té una especificació formal i un bon rendiment a la pràctica.
Alex: Quines són les vostres expectatives d'aquesta estructura de dades? Millorarà el rendiment en tots els casos habituals o és més adequat per a determinades situacions?
Michael: És útil si, en primer lloc, necessiteu un contenidor sense bloqueig i, en segon lloc, cal esperar en una situació en què necessiteu recuperar dades del contenidor que no hi és. Segons el meu millor coneixement, el nostre marc proporciona un comportament òptim quan es compleixen aquestes dues condicions. Per tant, en aquests casos recomano utilitzar-lo. El principal avantatge de les estructures de dades sense bloqueig és que eviten problemes de rendiment. I l'espera és molt important en molts algorismes si les dades es transfereixen d'un fil a un altre.
Виталий: Permeteu-me aclarir: parlareu del mateix tant a l'escola com a la conferència?
Michael: A l'escola en general, sobre estructures de dades multifils, amb els principis bàsics esbossats al principi de la lliçó. Suposo que el públic sap quins són els fils i està familiaritzat amb els bloquejos. A partir d'aquests coneixements bàsics, parlaré d'estructures de dades sense bloqueig. Donaré una visió general dels problemes més importants en aquesta àrea, tocant temes com la gestió de la memòria. No crec que hi hagi res més complicat que la cua de MS.
Alex: Teniu previst ensenyar sobre estructures de dades duals al final de la vostra classe a l'escola?
Michael: Els esmentaré, però no hi dedicaré gaire temps. A ells se'ls dedicarà l'informe Hydra. Cobrirà el projecte que finalment va arribar a Java, a més de treballar amb Joe Israelevich per crear una variant dual de la cua LCRQ i crear un disseny gairebé universal per a estructures de dades duals.
Alex: Per tant, la conferència a l'escola es pot recomanar per a principiants, i la conferència sobre estructures de dades dobles sobre Hydra, per a persones que ja tenen alguna experiència?
Michael: Corregiu-me si m'equivoco, però l'audiència d'Hydra serà força diversa, incloent molts experts en Java i, en general, gent que no està específicament implicada en la programació multiprocés.
Виталий: Sí, és cert.
Alex: Almenys ho esperem.
Michael: En aquest cas, em trobaré amb el mateix problema amb el que vam començar aquesta entrevista: com fer un reportatge alhora prou ric en detalls tècnics i accessible a tots els oients.
Виталий: Fareu un informe de la mateixa manera que feu conferències? És a dir, parlar amb el públic i adaptar-se a la situació?
Michael: Em temo que no funcionarà així, perquè l'informe tindrà diapositives. Les diapositives són importants quan els oients parlen inicialment diferents idiomes. A molta gent els costarà entendre'm en anglès, sobretot si parlo massa ràpid. Vaig triar aquests temes perquè em va demanar que parlés sobre estructures de dades sense bloqueig a l'escola SPTDC; i després necessitava un informe per a una conferència de grups d'usuaris de Java i volia triar alguna cosa que interessés específicament als programadors de Java. La manera més senzilla era parlar d'aquelles coses a la biblioteca de Java que jo tenia una mà d'una manera o altra.
Alex: Suposem que el públic d'Hydra ja sap alguna cosa sobre la programació sense bloqueig i potser té alguna experiència en aquesta àrea. Però això és només una suposició; la situació es farà més clara a la mateixa conferència. De totes maneres, gràcies pel teu temps. Estic segur que l'entrevista serà molt interessant per als nostres lectors. Moltes gràcies!
Виталий: Gràcies.
Michael: Estaré encantat de conèixer-vos a Sant Petersburg.
Alex: Nosaltres també tenim una ciutat preciosa. Has estat mai aquí?
Michael: No, no he estat mai a Rússia. Però Sant Petersburg sempre ha estat a la llista de llocs on encara no he estat, però on tinc moltes ganes d'anar, així que em va alegrar molt la invitació.
Alex: Per cert, tindrem un programa d'excursions per a ponents. Moltes gràcies per l'entrevista, i que tingueu un bon dia!
Podeu continuar la vostra conversa amb Michael a la conferència Hydra 2019, que se celebrarà de l'11 al 12 de juliol de 2019 a Sant Petersburg. Vindrà amb un informe . Les entrades es poden comprar .
Font: www.habr.com