Майкъл Скот - за 34 години като професор по компютърни науки в университета в Рочестър, а в родния си университет в Уисконсин-Медисън той е бил декан в продължение на пет години. Той изследва и обучава студенти за паралелно и разпределено програмиране и езиков дизайн.

Светът познава Майкъл от учебника "Прагматика на езика за програмиране", ами работата „Алгоритми за мащабируема синхронизация на мултипроцесори със споделена памет“ получи наградата Dijkstra като един от най-известните в областта на разпределените изчисления. Може да го познавате и като автора на същия алгоритъм Майкъл-Скот.

Заедно с Дъг Лий той разработи неблокиращи алгоритми и синхронни опашки, които захранват библиотеките на Java. Внедряване "двойни структури от данни" в JavaSE 6 подобрена производителност с 10 пъти ThreadPoolExecutor.

Съдържание:

• Ранна кариера, Университет на Рочестър. Проект Шарлот, език Lynx;
• IEEE мащабируем кохерентен интерфейс, MCS заключване;
• Оцеляване в един непрекъснато променящ се свят;
• Стават ли учениците по-глупави? Глобални тенденции, интернационализация;
• Ефективна работа с учениците;
• Как да сте в крак с подготовката на нови курсове и книги;
• Връзки между бизнеса и академичните среди;
• Практическа реализация на идеи. MCS, MS, CLH, JSR 166, работа с Дъг Лий и други;
• Транзакционна памет;
• Нови архитектури. Победата на транзакционната памет е близо;
• Енергонезависима памет, Optane DIMM, ултра-бързи устройства;
• Следващата голяма тенденция. Двойни структури от данни. Хидра.

Интервютата се провеждат от:

Виталий Аксенов — в момента постдокторант в IST Австрия и член на катедрата по компютърни технологии в университета ITMO. Провежда изследвания в областта на теорията и практиката на конкурентните структури от данни. Преди да работи в IST, той получава докторска степен от Парижкия университет Дидро и Университета ITMO под ръководството на професор Петър Кузнецов.

Алексей Федоров е продуцент в JUG Ru Group, руска компания, която организира конференции за разработчици. Алексей участва в подготовката на повече от 50 конференции, а автобиографията му съдържа всичко от позицията на инженер по разработка в Oracle (JCK, Java Platform Group) до позицията на разработчик в Odnoklassniki.

Владимир Ситников е инженер в Netcracker. В продължение на десет години той работи върху производителността и мащабируемостта на NetCracker OS, софтуер, използван от телекомуникационните оператори за автоматизиране на процесите на управление на мрежи и мрежово оборудване. Интересуват се от проблеми с производителността на Java и Oracle Database. Автор на над дузина подобрения на производителността в официалния JDBC драйвер на PostgreSQL.

Ранна кариера, Университет на Рочестър. Проект Charlotte, език Lynx.

Алекс: Като начало исках да ви кажа, че в Русия всички наистина обичаме компютърните науки, науката за данни и алгоритмите. Направо е неприлично. Прочетохме всичко книга от Cormen, Leiserson и Rivest. Следователно предстоящата конференция, училище и самото това интервю трябва да бъдат много популярни. Получихме много въпроси за това интервю от студенти, програмисти и членове на общността, така че сме много благодарни за тази възможност. Дали компютърните науки получават същата любов в САЩ?

Майкъл: Нашата област е толкова разнообразна, има толкова много посоки и влияе на обществото по толкова различни начини, че ми е трудно да ви дам категоричен отговор. Но факт е, че това доведе до огромни промени в бизнеса, индустрията, изкуството и обществото като цяло през последните 30 години.

Виталий: Да започнем с нещо далечно. В много университети има нещо като специализация в една определена област. За университета Карнеги Мелън това е паралелно изчисление, за MIT е криптография, роботи и многопоточност. Има ли такава специализация в университета в Рочестър?

Майкъл: За да бъда честен, бих казал, че CMU и MIT са специализирани във всички области. Нашият отдел винаги е обръщал най-голямо внимание на изкуствения интелект. Половината от хората, които работят за нас, са ангажирани с AI или взаимодействие човек-компютър – този дял е по-висок, отколкото в други отдели, и винаги е било така. Но когато бях в университета, нямах никакви курсове по ИИ и никога не съм работил в тази област. Така че моят отдел е специализиран в проблем, с който нямам нищо общо. Утехата е, че вторият по важност проблем за нашия отдел е паралелното и многонишково програмиране, тоест моята специализация.

Виталий: Започнахте да работите в областта на компютърните науки, когато полето на многопоточното програмиране едва се зараждаше. Списъкът на вашите публикации показва, че първите ви работи се занимават с доста широк кръг от въпроси: управление на паметта в многонишкови системи, разпределени файлови системи, операционни системи. Защо такава гъвкавост? Опитвали ли сте се да намерите своето място в изследователската общност?

Майкъл: Като ученик участвах в Проект Шарлот в Университета на Уисконсин, където е разработена една от първите разпределени операционни системи. Там работих заедно с Рафаел Финкел (Рафаел Финкел) и Марвин Соломон (Марвин Соломон). Дисертацията ми беше посветена на разработването на език за системен софтуер за разпределени системи - сега всички са забравили за това и слава богу. Създадох езика за програмиране Lynx, който имаше за цел да улесни създаването на сървъри за слабо свързана разпределена операционна система. Тъй като по това време се занимавах предимно с операционни системи, предполагах, че кариерата ми ще бъде свързана основно с тях. Но Рочестър беше много малък университет и поради това различните групи там взаимодействаха много тясно помежду си. Там нямаше дузина други хора за операционни системи, с които да говоря, така че всичките ми контакти бяха с хора, които работеха в напълно различни области. Наистина ми хареса, да съм многостранен е голямо предимство за мен. Ако говорим конкретно за многонишкови структури от данни и алгоритми за синхронизация, тогава започнах да работя върху тях напълно случайно.

IEEE мащабируем кохерентен интерфейс, MCS заключване.

Виталий: Можете ли да ми кажете малко повече за това?

Майкъл: Това е забавна история, която не се уморявам да разказвам на всички. Това се случи на конференция АСПЛОС в Бостън - това беше в края на 80-те или началото на 90-те години. Джон Мелор-Кръми (Джон Мелор-Кръми), възпитаник на нашия факултет. Познавах го, но досега не сме правили съвместни изследвания. Мери Върнън (Мери Върнън) от Уисконсин говори за многопроцесорна система, която разработват в Уисконсин: Уисконсин мултикуб. Този Multicube имаше механизъм за синхронизиране на хардуерно ниво, наречен Q on Sync Bit, а по-късно беше преименуван на Q on Lock Bit, защото звучеше като Colby cheese, което беше игра на думи. Ако се интересувате от многонишкови механизми, вероятно знаете, че Colby в крайна сметка се превърна в машината за синхронизиране на стандарта IEEE Scalable Coherent Interface. Това беше заключващ механизъм, който създава указатели от един кеш към друг на хардуерно ниво, така че всеки притежател на ключалка да знае чий е редът. Когато Джон и аз чухме за това, се спогледахме и казахме: защо да правим това на хардуерно ниво? Не може ли същото да се постигне с помощта на compare-and-swap? Взехме една от тетрадките, които лежаха в класната стая и драскахме върху нея MCS блокиране, докато Мери продължи доклада си. Впоследствие го реализирахме, експериментирахме, идеята се оказа успешна и публикувахме статията. По това време за мен тази тема изглеждаше просто забавно разсейване, след което планирах да се върна към операционните системи. Но тогава се появи друг проблем в същата посока и в крайна сметка синхронизацията, многонишковостта и структурите от данни станаха моя специалност. Както можете да видите, всичко това се случи случайно.

Виталий: Запознат съм с блокирането на MCS от дълго време, но досега не знаех, че това е ваша работа и не разбрах, че е акроним на вашите фамилни имена.

Как да оцелеем в един непрекъснато променящ се свят?

Алекс: Имам въпрос по свързана тема. Преди 30-40 години имаше повече свобода в различните специалности. Ако искате да започнете кариера в многонишкови или разпределени системи, добре дошли, ако искате да навлезете в операционни системи, няма проблем. Във всяка област имаше много открити въпроси и малко експерти. Сега се появиха тесни специализации: няма само експерти по операционни системи като цяло, има специалисти по отделни системи. Същото е и с многонишковите и разпределените системи. Но проблемът е, че животът ни не е безкраен; всеки може да посвети само няколко десетилетия на изследване. Как да оцелеем в този нов свят?

Майкъл: Ние не сме специални в това отношение, същото се случи веднъж и в други области. Имах късмет, че започнах да работя в областта на компютърните науки, когато областта беше в „тийнейджърските“ си години. Някои основи вече бяха положени, но всичко беше още много незряло. Тази възможност не се появява често. Електротехниката съществува от много дълго време, физиката още по-дълго, математиката почти от началото на времето. Но това не означава, че вече никой не прави интересни открития в математиката. Все още има много открити проблеми, но в същото време трябва да се научи повече. Прави сте да забележите, че сега има много повече специализации, отколкото е имало преди, но това означава само, че се намираме в същата ситуация като повечето други области на човешката дейност.

Алекс: Тук ме интересува по-практичният аспект на въпроса. Имам математически опит и по време на следването си често посещавах конференции и работех по различни научни теми. Открих, че никой от публиката не разбира моите доклади и по същия начин докладите на други хора са разбираеми само за тях самите. Това не е така при темите на високо ниво, но щом започнеш да се задълбочаваш в нещо, публиката вече не може да се справи с теб. Как се справяте с това?

Майкъл: Не винаги успешно. Наскоро подготвих доклад, в който навлязох твърде дълбоко в технически подробности. С напредването на разговора стана ясно, че по-голямата част от публиката не ме разбира, така че трябваше да се адаптирам към ситуацията в движение. Слайдовете не можеха да се сменят, така че не се получи много добре - така че, общо казано, гледам да не използвам слайдове. Като цяло моят съвет е да се съобразите с аудиторията си. Трябва да знаете с кого говорите, какво е тяхното ниво на познания и какво трябва да чуят, за да оценят работата ви.

Виталий: Бихте ли ни подсказали за какво беше тази лекция?

Майкъл: Честно казано, бих предпочел да не разширявам тази тема, за да оставя въпросните хора анонимни. Въпросът е, че често навлизаме твърде дълбоко в тънкостите на проблема, върху който работим, така че ни е трудно да обясним в началото на разговора защо проблемът е интересен и важен и каква е връзката му с въпроси, които публиката вече знае. По мои наблюдения учениците най-трудно усвояват това умение. И това също беше слабото място на последния ми доклад. Правилно структурираният репортаж трябва още в самото начало да намери контакт с аудиторията, да й обясни какъв точно е проблемът и как той се отнася към вече познатите й теми. Колко технически е това въведение зависи от аудиторията. Ако е напълно пъстър, тогава докладът може да бъде многоетапен. Въведението трябва да е достъпно за всеки и до края парчето може да не е в крак с вас, но хората, които са относително запознати с вашата област, ще могат да го разберат.

Стават ли учениците по-глупави? Глобални тенденции, интернационализация.

Алекс: Наблюдавате ученици от няколко десетилетия. Стават ли учениците по-глупави или по-умни от десетилетие на десетилетие или година на година? В Русия преподавателите непрекъснато се оплакват, че студентите стават все по-глупави всяка година и наистина не е ясно какво да се прави по въпроса.

Майкъл: Наистина можете да чуете много негативизъм от нас, старите хора. Подсъзнателно имаме склонност да очакваме учениците да усвоят всичките 30 години опит, които вече имаме. Ако аз имам по-дълбоко разбиране от това, което имах през 1985 г., защо учениците го нямат? Сигурно защото са на 20 години, как мислите? Мисля, че най-значимите промени през последните десетилетия са в демографския състав: сега имаме значително повече международни студенти, с изключение на канадците. Преди имаше много канадци, защото сме много близо до границата с Канада и студентите от там могат да пътуват до вкъщи през уикендите. Но сега в Канада има много добри университети и канадците предпочитат да учат тук; значително по-малко от тях идват в САЩ.

Алекс: Смятате ли, че това е местна тенденция или глобална?

Майкъл: Не помня точно кой, но някой каза, че светът е плосък. Нашата област стана много по-международна. Конференции на ACM Преди това те се провеждаха изключително в Съединените щати, след това решиха да ги провеждат веднъж на всеки 4 години в други страни, а сега се провеждат по целия свят. Тези промени засегнаха още повече IEEE, тъй като винаги е била по-международна организация от ACM. И има програмни председатели от Китай, Индия, Русия, Германия и много други страни, защото сега навсякъде се случва много.

Алекс: Но вероятно има някои негативни аспекти на такава интернационализация?

Майкъл: Бих казал, че всички негативни аспекти са свързани не с технологиите, а с политиката. Имало едно време основният проблем беше фактът, че САЩ крадяха най-умните и талантливи хора от страни по света. И сега основният проблем са политическите игри между различните държави около визите и имиграцията.

Алекс: Тоест, бариери и подобни неща. Ясно е.

Владимир: Лично на мен ми е интересно какъв подход възприемате, когато преподавате нов предмет на учениците. Има различни опции: можете да се опитате първо да ги вдъхновите да опитат нещо ново или можете да обърнете повече внимание на детайлите за това как работи определена технология. Какво предпочитате?

Ефективна работа с учениците

Алекс: А как да намерим проклетия баланс между първото и второто?

Майкъл: Проблемът е, че часовете не винаги протичат така, както бих искал. Обикновено давам на учениците материал за четене предварително, така че да се задълбочат в него, да го разберат по най-добрия възможен начин и да формулират въпроси относно онези части, които не могат да разберат. Тогава в клас можете да се съсредоточите върху най-трудните моменти и да ги изследвате заедно. Така най-много обичам да водя часове. Но предвид натоварването, което сега лежи върху учениците, не винаги мога да се уверя, че те се подготвят предварително. В резултат на това трябва да отделите много повече време за общия преразказ на материала, отколкото бихте искали. Въпреки това се опитвам да запазя часовете ни интерактивни. В противен случай е по-лесно да запишете видеоклип веднъж, който учениците могат да гледат вкъщи. Смисълът на класовете на живо е човешкото взаимодействие. В клас предпочитам да използвам тебешир и черна дъска, а не слайдове, освен в определени случаи, когато диаграмата е твърде сложна, за да бъде изобразена на дъската. Благодарение на това не ми се налага да се придържам към строг план на урока. Тъй като няма строг ред, в който давам материала, това ми позволява да го адаптирам към аудиторията в зависимост от въпросите, които получавам. Като цяло се опитвам да направя часовете възможно най-интерактивни, така че материалът, който представям, да зависи от въпросите, които ми се задават.

Владимир: Чудесно е. Според моя опит е доста трудно да накараш слушателите да задават въпроси. Дори и да помолите предварително да задавате някакви въпроси, без значение колко са глупави или умни, те пак мълчат. Как се справяте с това?

Майкъл: Ще се смеете, но ако стоите мълчаливо достатъчно дълго, рано или късно на всички ще стане неудобно и някой ще зададе въпрос. Или можете да зададете прост технически въпрос с отговор да или не, за да определите дали хората разбират току-що казаното. Например, има ли надпревара за данни в примера по-горе? Кой мисли така? Кой мисли, че не? Кой изобщо нищо не разбира, защото общо само половината ръце се вдигнаха?

Виталий: И ако сте отговорили неправилно, ще бъдете изхвърлени от час :)

Майкъл: Ако не сте отговорили на нищо, трябва да зададете въпрос. Трябва да разбера какво точно трябва да знае ученикът, за да отговори на въпроса, който току-що зададох. Имам нужда от тях да ми помогнат да им помогна. Готов съм да се адаптирам към тях, за да разберат проблема. Но ако не знам какво се случва в главата им, не мога да го направя. И ако не дадете мира на учениците достатъчно дълго време, понякога накрая те задават правилните въпроси, тоест такива, които ми позволяват да видя какво точно се случва в главите на учениците. 

Алекс: Тези въпроси водят ли понякога до идеи, за които самият вие не сте се сещали преди? Неочаквани ли са? Позволяват ли ви да погледнете проблема в нова светлина?

Майкъл: Има въпроси, които отварят нов начин за представяне на материала. Често има въпроси, които водят до интересни проблеми, за които не съм планирал да говоря. Студентите често ми казват, че имам склонност да се отклонявам от темата, когато това се случи. И според тях много често това е най-интересната част от урока. Много рядко, само няколко пъти, студентите задаваха въпроси, които подтикнаха нова посока в изследването и прераснаха в статия. Това се случва много по-често в разговори с ученици, отколкото по време на занятия, но понякога се случва по време на занятия. 

Алекс: Значи студентите ви задаваха въпроси, въз основа на които тогава беше възможно да публикувате статия?

Майкъл: Да. 

Виталий: Колко често провеждате тези разговори със студенти? Кога искат да научат повече от това, което беше разгледано по време на урока?

Майкъл: С моите дипломанти – през цялото време. Имам около 5 или 6 от тях и непрекъснато обсъждаме нещо с тях. И разговори от този тип със студенти, които просто посещават часовете ми, не са много чести. Въпреки че ми се иска това да се случва по-често. Подозирам, че те просто се страхуват да идват във факултета в работно време. Всеки семестър някои студенти успяват да преодолеят тази психологическа бариера и винаги е много интересно да се говори с тях след час. Вярно е, че ако всички ученици бяха толкова смели, просто нямаше да ми стигне времето. Така че може би всичко работи както трябва. 

Виталий: Как успявате да намерите време за общуване със студентите? Доколкото знам, в САЩ учителите имат много работа - кандидатстват за грантове и тем подобни. 

Майкъл: Честно казано, работата със студенти е аспектът от моята работа, който най-много ми харесва. Така че имам достатъчно мотивация за това. По-голямата част от времето, което прекарвам в офиса си, е изразходвано за срещи от всякакъв вид. Сега е лято, така че графикът ми е по-малко натоварен, но през учебната година всеки ден от 9 до 17 имам всичко опаковано. Изследователска работа, рецензии, стипендии - за всичко това има само вечери и уикенди. 

Как да сте в крак с подготовката на нови курсове и книги.

Алекс: В момента продължавате ли да преподавате курсове, които преподавате от дълго време? Нещо като въведение в компютърните науки.

Майкъл: Първото нещо, което идва на ум тук е курс по езици за програмиране. 

Алекс: Колко различна е днешната версия на този курс от това, което беше преди 10, 20, 30 години? Може би това, което е по-интересно тук, не са подробностите на конкретен курс, а общите тенденции.

Майкъл: Моят курс по езици за програмиране беше малко необичаен по времето, когато го създадох. Започнах да го чета в края на 1980-те, замествайки колегата си Дъг Болдуин (Дъг Болдуин). Темата на курса беше само косвена свързана с моята специалност, но когато той напусна, аз бях най-добрият кандидат за преподаване на курса. Не харесвах нито един от учебниците, които съществуваха по онова време, така че в крайна сметка сам написах учебника за този курс. (Бел.ред.: говорим за книгата "Прагматика на езика за програмиране") Сега се използва в повече от 200 университета по света. Моят подход е необичаен с това, че умишлено смесва проблемите на дизайна и изпълнението на езика и обръща голямо внимание на взаимодействието между тези аспекти във всички възможни области. Основният подход остава непроменен, както и много основни концепции: абстракции, пространства от имена, модулност, типове. Но наборът от езици, с които се демонстрират тези концепции, се е променил изцяло. Когато курсът беше създаден за първи път, имаше много примери в Pascal, но днес много от моите ученици дори не са чували за този език. Но те знаят Swift, Go, Rust, така че трябва да говоря за езиците, които се използват днес. Освен това студентите вече са добре запознати със скриптовите езици, но когато започнах да преподавам този курс, всичко беше свързано с компилирани езици. Сега имаме нужда от много материали за Python, Ruby и дори Perl, защото това е кодът, който се пише в наши дни и има много интересни неща, които се случват на тези езици, включително в областта на езиковия дизайн. 

Виталий: Тогава следващият ми въпрос ще е свързан с предишния. Как да се поддържаме в тази област? Подозирам, че актуализирането на курс като този изисква много работа - трябва да разбирате нови езици, да разбирате основните идеи. как го правиш

Майкъл: Не мога да се похваля, че винаги успявам на 100%. Но през повечето време просто правя това, което правят всички останали – чета интернет. Ако искам да разбера Rust, пускам го в Google, отивам на страницата на Mozilla и чета ръководството, публикувано там. Това е част от нещата, които се случват в комерсиалното развитие. Ако говорим за наука, тогава трябва да следвате докладите на основните конференции. 

Връзка между бизнеса и академичните среди

Виталий: Да поговорим за връзката между бизнеса и научните изследвания. В списъка ви с произведения намерих няколко статии за кохерентността на кеша. Разбирам, че алгоритмите за съгласуваност на кеша са били нестабилни по време на публикуването им? Или не е достатъчно разпространена. Колко разпространени бяха вашите идеи на практика?

Майкъл: Не съм сигурен точно за кои публикации говорите. Свърших доста работа с моите ученици Бил Болоски (Уилям Болоски) и Леонидас Контотанасис (Леонидас Контотанасис) в началото на 1990-те години за управление на паметта на машините на Нойман. По това време бизнесът все още не е имал разбиране как правилно да се направи многопроцесорна система: струва ли си да се създаде поддръжка за достъп до отдалечена памет на хардуерно ниво, струва ли си да се направи паметта разпределена, възможно ли е да се зареди кешът от отдалечена памет или е необходимо да се преместват страници в операционната система? И Бил, и Леонидас работеха в тази област и изследваха подходи без дистанционно зареждане на кеша. Това не беше пряко свързано с кохерентността на кеша, но все още беше работа върху управлението на паметта NUMA и впоследствие модерните подходи за разполагане на страници в съвременните операционни системи израснаха от това. Като цяло Бил и Леонидас свършиха важна работа, макар и не най-влиятелната в тази област - имаше много други хора, работещи по същото нещо по това време. По-късно работих по тема, свързана с кохерентността на кеша в контекста на хардуерната транзакционна памет. Групата, с която работих по този проблем, получи няколко патента. Зад тях стоят доста интересни идеи, но не мисля, че ще бъдат реализирани на практика. По един или друг начин ми е трудно да преценя тяхната доходност. 

Алекс: В тази връзка един по-личен въпрос: колко е важно за вас идеите ви да бъдат реализирани? Или не мислиш за това?

Майкъл: Обичам да задавам този въпрос в интервюта с други хора, кандидати или кандидати, които искат да се присъединят към факултета. Не мисля, че има правилен отговор на този въпрос. Хората, които правят готини неща, могат да имат много различни мотивации. Привличат ме проблемите, защото аз лично ги намирам за интересни, а не заради практическите им ползи. Но от друга страна, когато нещо интересно все пак намери приложение, много ми харесва. Така че тук не е лесно. Но в началото на работата си все още съм воден не от идеята за крайна употреба в света, а от хармонията на идеята и желанието да я изследвам и да видя какво ще излезе от нея. Ако в крайна сметка даде практически резултати, чудесно. 

Алекс: Благодарение на вашето образование и опит вие сте по-способни от повечето да преценявате стойността на идеите на други хора. Можете да ги сравните и да определите кое с кое работи по-добре. Сигурен съм, че имате мнение за неща, които в момента се използват на практика от големи производители като Intel. От ваша гледна точка доколко правилен е курсът, който поемат тези компании?

Майкъл: Практиката винаги се върти около това, което може да бъде търговски успешно, тоест да създаде печалба, и по-добре попитайте някой друг за това. Работата ми води най-вече до публикации, а в областта на операционните системи те се оценяват по показатели за производителност: скорост, консумация на енергия, размер на кода. Но винаги ми се струваше, че тези емпирични резултати се добавят към статии само за да могат да бъдат публикувани, а истинските мотиви за работа на хората са естетически. Изследователите оценяват решенията от артистична гледна точка, интересуват се колко елегантни са идеите и се опитват да създадат нещо по-добро от съществуващите подходи. Изследователите са водени от лични, субективни, естетически мотиви. Но не можете да пишете за това в самата статия, тези неща не са аргументи за програмната комисия. За щастие елегантните решения често са бързи и евтини. Дузина мои колеги и аз обсъждахме тази тема преди около 15 години и в крайна сметка написахме статия за нея. Мисля, че все още можете да го намерите сега, нарича се „Как да оценим системните изследвания“ или нещо подобно, има повече от дузина автори. Това е единствената статия, в която аз съм автор заедно с Саша Федорова, така че ако потърсите нейното име в моя списък с публикации, ще намерите това, от което се нуждаете. Той говори за оценка на системните изследвания и колко важна е елегантността. 

Алекс: Така че има разлика между стандарта за това, което се смята за добро в науката и в бизнеса. Науката оценява производителността, консумацията на енергия, TDP, лекотата на внедряване и много повече. Имате ли възможност да провеждате такъв тип изследвания в университета? Имате ли лаборатория с различни машини и различни архитектури, в които бихте могли да провеждате експерименти?

Майкъл: Да, нашият отдел разполага с много различни интересни машини. Най-често те са малки, имаме малък клъстер и много мултипроцесорни системи с различни ускорители. Освен това в кампуса има огромен изчислителен център, който обслужва учени от няколко десетки различни дисциплини. Има около хиляда възли и двадесет хиляди ядра, всички на Linux. Ако възникне нужда, винаги можете да закупите AWS. Така че нямаме значителни ограничения по отношение на хардуера. 

Алекс: Какво беше преди тридесет години? Тогава имаше ли проблеми?

Майкъл: Тогава беше малко по-различно. В средата до края на 1980-те години се смяташе, че науката изпитва недостиг на изчислителни ресурси. За да коригира тази ситуация, Националната научна фондация (Национална научна фондация) създаде програма за координирани експериментални изследвания (Coordinated Experimental Research, CER). Мисията на програмата беше да осигури изчислителна инфраструктура за отделите по компютърни науки и постигна значителна промяна. С парите, които тя предостави, ние от университета в Рочестър купихме 1984-възела BBN Butterfly през 128 г., това беше една година преди да пристигна там. По това време това беше най-голямата многопроцесорна система в света със споделена памет. Имаше 128 процесора, всеки на отделна дънна платка, и заемаше четири шкафа. Всеки процесор имаше мегабайт памет, 128 мегабайта RAM бяха невъобразимо количество по онова време. На тази машина внедрихме MCS заключване за първи път. 

Алекс: Значи, ако те разбирам правилно, то в момента проблемът с хардуера е решен? 

Майкъл: Като цяло, да. Има няколко предупреждения: първо, ако правите компютърна архитектура на ниво чип, това е трудно да се направи в академична среда, защото има много по-добри инструменти за това в бизнеса. Ако имате нужда от нещо по-малко от 10 нанометра, ще трябва да го поръчате от някой друг. В тази област е много по-лесно да си изследовател в Intel. Ако работите върху оптични комуникации на чипове или на твърдотелна памет, ще намерите технологии в бизнеса, които все още не са в науката, така че трябва да създадете съюзи. Например Стивън Суонсън (Стивън Суонсън) създаден такова партньорство за нови технологии за памет. Тази форма не винаги работи, но в някои случаи може да бъде доста успешна. Освен това в науката разработването на най-мощните изчислителни системи е по-трудно. Най-големите проекти за суперкомпютри в момента в САЩ, Япония и Китай са фокусирани върху бизнеса. 

Практическа реализация на идеи. MCS, MS, CLH, JSR 166, работа с Дъг Лий и др.

Виталий: Вече говорихте как сте започнали да работите върху алгоритми за синхронизация. Имате две много известни статии за MCS блокиране и Опашка на Майкъл-Скот (MS), които в известен смисъл бяха реализирани в Java. (Бележка на редактора: всички публикации могат да бъдат разгледани по ссылке). Там това блокиране беше реализирано с някои промени и се получи CLH ключалкаи опашката беше внедрена по предназначение. Но между публикуването на Вашите статии и тяхното практическо приложение минаха много години. 

Алекс: Изглежда около 10 години в случая с опашката.

Майкъл: Преди тези функции да се появят в стандартната библиотека на Java?

Виталий: Да. Какво направихте, за да се случи това? Или не направиха нищо?

Майкъл: Мога да ви кажа как MS Queue влезе в Java 5. Няколко години преди да се появи, работих с групата на Марк Мойърс в Sun Microsystems в тяхната лаборатория близо до Бостън. Той организира семинар за хора, които познаваше, които работеха върху интересни проблеми в многопоточността, защото искаше да намери теми, които да продаде на тяхната компания. Там за първи път срещнах Дъг Лиа. Дъг и аз и още около 25 души от Sun обсъждахме заедно презентацията на Дъг JSR 166, който по-късно стана java.util.concurrent. По пътя Дъг каза, че би искал да използва MS опашката, но за това му трябва брояч за броя на елементите в опашката за интерфейса. Тоест това трябваше да стане по отделен метод, атомен, точен и бърз. Предложих просто да добавите серийни номера към възлите, като вземете номера на първия възел и последния и извадите единия от другия. Дъг се почеса по главата, каза „защо не“ и в крайна сметка направи точно това. Обсъдихме прилагането на този подход в библиотеката, но Дъг свърши по-голямата част от работата сам. В резултат на това той успя да установи отлична многонишкова поддръжка в Java. 

Алекс: Така че, ако разбирам правилно, методът .size() трябваше да е част от стандартния интерфейс на опашката и трябваше да има алгоритмична сложност O(1)?

Майкъл: Да, и в допълнение към това е необходим отделен брояч.

Алекс: Защото, ако извикате метода .size() в Java, резултатът се очаква да бъде достъпен веднага, а не въз основа на действителния размер на колекцията. Разбирам, благодаря.

Майкъл: Няколко години по-късно работих върху двойни структури от данни с моя ученик Бил Шерер - всъщност това е, за което ще говоря доклад за Hydra. Дъг дойде при нас и каза, че може да ги използва в Java Executor Framework. Заедно с Бил те създадоха две реализации, така наречените справедливи и несправедливи опашки. Посъветвах ги за този проект, въпреки че не участвах в писането на действителния код. В резултат на това скоростта на изпълнителите се е увеличила значително. 

Владимир: Срещали ли сте неправилни реализации на вашите алгоритми или заявки за добавяне на нови функции? По принцип практиката трябва да съвпада с теорията, но доста често се различават. Да предположим, че сте написали алгоритъм и на хартия той работи, но хората, които участват в внедряването, започнаха да ви молят за повече функции или някаква настройка на алгоритъма. Имали ли сте някога такива ситуации?

Майкъл: Единственият пример, в който някой дойде при мен и ме попита „как да го приложа“, беше въпросът на Дъг, за който вече говорих. Но има няколко случая, в които са направени интересни промени, за да отговарят на практическите нужди. Например, екипът на K42 в IBM преобразува заключването на MCS и го направи стандартен интерфейс, така че няма нужда да се предава възелът на опашката напред и назад към рутинните процедури за придобиване и освобождаване. Благодарение на този стандартен интерфейс една идея, която беше красива на теория, започна да работи на практика. Изненадващо е, че никога не са публикували статия за това и въпреки че са получили патент, по-късно са го изоставили. Идеята беше чудесна и се опитвам да говоря за нея, когато е възможно. 

Имало е и други случаи, в които хора са правили подобрения на публикуваните от мен алгоритми. Например MS опашката има механизъм за инсталиране в две стъпки, което означава, че има два CAS на критичния път на опашката. При по-старите коли CAS бяха доста скъпи. Intel и други производители ги оптимизираха доста добре напоследък, но преди време това бяха инструкции от 30 цикъла, така че наличието на повече от една на критичния път беше нежелателно. В резултат на това беше разработена различна опашка, която беше подобна на MS опашката, но която имаше само една атомна операция по критичния път. Това беше постигнато поради факта, че през определен период от време операцията можеше да отнеме O(n) време, а не O(1). Беше малко вероятно, но възможно. Това се дължи на факта, че в определени моменти алгоритъмът обхожда опашката от началото до текущата позиция в тази опашка. Като цяло алгоритъмът се оказа много успешен. Доколкото знам, не се използва много широко, отчасти защото атомните операции изискват значително по-малко ресурси от преди. Но идеята беше страхотна. Много харесвам и работата на Дейв Дайс от Oracle. Всичко, което прави, е много практично и използва желязото много умело. Той имаше пръст в голяма част от алгоритмите за синхронизация, поддържащи NUMA, и многонишковите структури от данни. 

Владимир: Когато пишете алгоритми или преподавате на ученици, резултатът от работата ви не се вижда веднага. Общността се нуждае от известно време, за да се запознае, да речем, с нова статия. Новият алгоритъм не намира приложение веднага. 

Майкъл: Далеч не е ясно веднага дали статията ще бъде значима или не. Мисля, че би било интересно да се направи проучване на доклади, които са спечелили награди на конференции. Тоест вижте статиите, които хората от програмните комисии по едно време смятаха за най-добри. Трябва да се опитате да изчислите по броя на връзките и въздействието върху бизнеса колко влиятелни наистина са се оказали тези статии след 10, 20, 25 години. Съмнявам се, че ще има силна връзка между двете. Няма да е нула, но най-вероятно ще бъде много по-слаба, отколкото бихме искали. Много идеи остават непотърсени дълго време, преди да станат широко разпространени. Например, нека вземем транзакционната памет. Изминаха повече от 10 години от публикуването на оригиналната статия до момента, в който хората наистина започнаха да създават машини с нея. И преди появата на тази памет в търговски продукти - и всички 20. Много дълго време никой не обърна внимание на статията, а след това броят на връзките към нея рязко се увеличи. Би било трудно да се предвиди това предварително. От друга страна, понякога идеите веднага намират реализация. Преди няколко години написах статия с Джо Израелевич за DISC, която предложи нова формална дефиниция на валидност за постоянни структури от данни, които могат да се използват, след като компютърът, който ги изпълнява, се срине. Статията ми хареса от самото начало, но се оказа много по-популярна, отколкото очаквах. Той беше използван от няколко различни групи и в крайна сметка се превърна в стандартна дефиниция на постоянни структури. Което, разбира се, е хубаво.

Владимир: Има ли техники, които използвате за оценка? Опитвате ли се дори да оценявате вашите статии и вашите ученици? По отношение на това дали човекът, на когото си преподавал, върви в правилната посока.

Майкъл: Като всеки друг, и аз обръщам повече внимание на това, което правя в момента. Отново, като всеки друг, от време на време проверявам Google Scholar, за да видя дали моите предишни статии са цитирани, но това е по-скоро от любопитство. Най-вече съм погълнат от това, което моите ученици правят сега. Когато става въпрос за оценка на текущата работа, част от това са естетически съображения, кое е елегантно и кое не. А на ежедневно ниво откритите въпроси играят голяма роля. Например, ученик идва при мен с графика на някакви резултати и ние се опитваме да разберем откъде идва някакво странно поведение на графиката. Като цяло в работата си постоянно се опитваме да разберем неща, които все още не разбираме. 

Транзакционна памет

Виталий: Може би можем да поговорим малко за транзакционната памет?

Майкъл: Мисля, че си струва да кажа поне малко, защото положих много усилия. Това е тема, по която имам повече публикации от всяка друга. Но в същото време, колкото и да е странно, винаги съм бил много скептичен относно транзакционната памет. По мое мнение, статия от Herlihy и Moss (M. Herlihy, J. E. B. Moss) е публикувана преди времето си. В началото на 1990-те те предполагат, че транзакционната памет може да помогне на талантливи програмисти да работят върху многонишкови структури от данни, така че тези структури след това да могат да се използват като библиотеки от обикновени програмисти. Тоест, това би било от помощ за Дъг Лий да прави своя JSR 166. Но транзакционната памет не е предназначена да направи многопоточното програмиране лесно. Но точно така започна да се възприема в началото на 2000-те години, когато стана масово. Беше рекламиран като начин за решаване на проблема с паралелното програмиране. Този подход винаги ми се е струвал безнадежден. Транзакционната памет може само да улесни писането на паралелни структури от данни. Това, струва ми се, е постигнала. 

За трудността при писане на многонишков код

Алекс: Много интересно. Изглежда има известна бариера между обикновените програмисти и тези, които могат да пишат многонишков код. Миналата година говорих няколко пъти с хора, които прилагаха някаква алгоритмична рамка. Например с Мартин Томсън, както и с програмисти, работещи върху многонишкови библиотеки. (Бележка на редактора: Мартин Томпсън е много известен разработчик, пише той разкъсване и Aeron. И той също има докладът на нашата конференция Joker 2015, видеозапис наличен в YouTube. Той е същият отвори тази конференция основен запис също достъпно). Основното предизвикателство, казват те, е да направят алгоритмите едновременно бързи и лесни за използване. Тоест те се опитват да преодолеят тази бариера и да привлекат колкото се може повече хора в тази област. Какво мислиш за това?

Майкъл: Това е основният проблем на многопоточността: как да се постигне висока производителност, без да се увеличава сложността на системата. 

Алекс: Защото, когато се опитват да избегнат сложността, алгоритъмът става по-малко универсален.

Майкъл: Ключът тук са правилно проектираните абстракции. Струва ми се, че това като цяло е основното за компютърните системи като сфера. Бътлър Лампсън обича да използва този термин и ни нарича „търговци на абстракции“. Днес простите технологии не съществуват. Процесорите, които използваме, имат 10 милиарда транзистора - простотата е изключена. В същото време ISA е много по-опростен от процесора, тъй като работихме много дълго време, за да му осигурим висока производителност и сравнително прост интерфейс. Но и при нея не всичко е гладко. Същият проблем е и с ускорителите, които сега се появяват на пазара. Възникват въпроси - как да се направи правилният интерфейс за GPU, механизъм за криптиране, компресия, механизъм за транскодиране, механизъм за линейна алгебра или дори по-гъвкав FPGA. Как да създадете интерфейс, който прави инструмента лесен за използване и скрива сложността? Няма да се отърве от него, а по-скоро ще го скрие от обикновен програмист. 

Алекс: Доколкото разбирам, все още имаме бариера в разбирането на абстракциите. Да вземем модела на паметта; на нашия етап от развитието на науката и технологиите това е една от основните абстракции. Благодарение на него всички програмисти се разделят на две групи: по-голямата част са тези, които не го разбират, и по-малката част са тези, които разбират или смятат, че разбират. 

Майкъл: Това е добър въпрос – дали някой от нас наистина разбира модела на паметта?

Виталий: Особено в C++.

Майкъл: Говорете с Hans Boehm някой път. Той е един от най-умните хора, които познавам, водещ експерт по модели на паметта. Той веднага ще ви каже, че има много неща, които не разбира. Но ако се върнем към въпроса за абстракциите, тогава според мен беше изразена най-важната идея в областта на моделите на паметта през последните 30 години в дисертацията на Сарита Адве. (Бележка на редактора: наличен е пълен списък с публикации по ссылке).

Алекс: Въпросът ми е: тази бариера идва ли от самото естество на концепцията? 

Майкъл: Не. Сарита стигна до извода, че с правилния подход можете успешно да скриете цялата сложност, да получите висока производителност и да дадете на програмиста прост API. И ако следвате този API, можете да постигнете последователна последователност. Мисля, че това е правилният модел. Пишете код без състезания за данни и получете последователна последователност. Разбира се, за да се намали вероятността от състезания, са необходими специални инструменти, но това е друг въпрос. 

Владимир: Имало ли е моменти в кариерата ви, когато проблем, който изглеждаше разрешен, внезапно се превръщаше в катастрофа или се оказваше, че този проблем е неразрешим? Например, на теория можете да разложите всяко число или да определите дали някое число е просто. Но на практика това може да бъде трудно да се направи; с текущия хардуер е трудно да се факторират числата. Случвало ли ви се е нещо подобно?

Майкъл: Не си спомням веднага нещо подобно. Имало е моменти, в които ми се е струвало, че няма какво повече да се прави в определен район, но тогава там се е случвало нещо ново и интересно. Например, мислех, че областта на неограничените опашки вече е достигнала зрялост. След няколко подобрения на опашката на MNS вече не се случи нищо особено. И тогава Морисън (Адам Морисън) и Афек (Йехуда Афек) изобретиха LCRQ опашка. Стана ясно, че е възможна неограничена многонишкова опашка, където през повечето време има само инструкция за извличане и увеличаване на критичния път. И това направи възможно постигането на порядък по-добра производителност. Не че не знаем, че fetch-and-increment е много полезно нещо. Ерик Фройдентал пише за това в работата си върху ултракомпютъра с Алън Готлиб в края на 1980-те години, но става въпрос за ограничени опашки. Морисън и Афек успяха да използват извличане и увеличаване на неограничена опашка.

Нови архитектури. Близо ли е победата на транзакционната памет?

Владимир: Търсите ли нови архитектурни решения, които биха могли да бъдат полезни за алгоритмите? 

Майкъл: Разбира се, има много неща, които бих искал да видя изпълнени. 

Владимир: Какви например?

Майкъл: Първо, няколко прости разширения на нашата транзакционна памет на хардуерно ниво в процесори Intel и IBM. По-специално, бих искал не-транзакционното зареждане и съхраняване, които току-що възникнаха, да бъдат незабавно достъпни в транзакциите. Те незабавно водят до цикли в последователността случва-преди, така че могат да бъдат трудни. Но ако поддържате слоеве на абстракция, има много много интересни неща, които можете да правите извън транзакцията, докато тя се случва. Не знам колко трудно би било това да се приложи, но би било много полезно. 

Друго полезно нещо е зареждането на кеша от отдалечената памет. Мисля, че рано или късно това ще стане. Тази технология ще позволи създаването на системи с дезагрегирана памет. Би било възможно да се съхраняват, да речем, 100 терабайта енергонезависима памет в стелаж и самата операционна система динамично да решава кои секции от тази памет трябва да съответстват на физическото адресно пространство на процесорите. Това би било изключително полезно за облачни изчисления, тъй като би позволило да се предоставят големи количества памет за задачите, които се нуждаят от нея. Мисля, че някой ще го направи.

Виталий: За да завършим разговора за транзакционната памет, имам още един въпрос по тази тема. Ще замени ли транзакционната памет в крайна сметка стандартните многонишкови структури от данни?

Майкъл: Не. Транзакциите са спекулативен механизъм. На ниво програмиране това са атомни брави, но вътре са спекулации. Такова прогнозиране работи, ако повечето предположения са верни. Следователно транзакционната памет работи добре, когато нишките почти не взаимодействат помежду си и просто трябва да се уверите, че няма взаимодействия. Но ако съобщение започне между нишки, транзакциите нямат голяма полза. Нека обясня, говорим за случая, когато транзакциите са обвити около цялата атомна операция. Те все още могат успешно да се използват като компоненти за многонишкови структури от данни. Например, ако имате нужда от CAS от три думи и трябва да направите многонишкови три малки неща в средата на един наистина многонишков алгоритъм, който работи с двадесет нишки едновременно. Като цяло транзакциите могат да бъдат полезни, но те няма да премахнат необходимостта от правилно проектиране на многонишкови структури от данни. 

Енергонезависима памет, Optane DIMM, ултра-бързи устройства.

Виталий: Последното нещо, за което бих искал да говоря, е темата на настоящото ви изследване: енергонезависима памет. Какво можем да очакваме в тази област в близко бъдеще? Може би знаете за някакви ефективни реализации, които вече съществуват? 

Майкъл: Не съм хардуерен експерт, знам само това, което чета в новините и това, което ми казват колегите. Всички вече са чували, че Intel продава Optane DIMM, които имат около 3 пъти по-голяма латентност при четене и 10 пъти по-голяма латентност при запис от динамичната RAM. Те скоро ще бъдат налични в много големи версии. Смешно е да си помислите, че бихте могли да имате лаптоп с няколко терабайта RAM с байтова адресация. Вероятно след 10 години ще решим да използваме тази нова технология, тъй като използваме DRAM - просто увеличете обема. Но благодарение на енергийната независимост пред нас се отварят напълно нови възможности. Можем фундаментално да променим стека за съхранение, така че да няма разделение между байт-адресируемата работна памет и блоково-структурираната постоянна памет. По този начин няма да е необходимо да сериализираме всичко, което трябва да бъде прехвърлено от една програма в друга, в блоково структурирани файлове. От това можем да извлечем много важни принципи, които засягат операционните системи, средите за изпълнение и разпределените хранилища на данни. Тази сфера е много интересна за работа. Лично за мен е трудно да предвидя до какво ще доведе всичко това, но проблемите тук са изключително забавни. Тук може да има революционни промени и те следват много естествено от работата по многонишковостта, тъй като възстановяването при повреда е "многонишков" процес до нормалната работа на системата. 

Втората основна тема, върху която работя в момента, е управлението на ултра-бързи устройства и защитен достъп до устройства от потребителското пространство със системен контрол на правилата. През последните години се наблюдава тенденция за преместване на достъпа до устройството в потребителското пространство. Това се прави, защото TCP-IP стекът на ядрото не може да функционира върху мрежов интерфейс, който се нуждае от нов пакет на всеки 5 микросекунди; той просто няма да се справи. Поради това производителите осигуряват директен достъп до устройствата. Но това означава, че операционната система губи контрол над процеса и не може да осигури правилен достъп до устройството за конкурентни приложения. Нашият изследователски екип вярва, че този недостатък може да бъде избегнат. Ще имаме статия за това в USENIX ATC този месец. Това е свързано с работата върху постоянството, тъй като дълготрайната постоянна памет с байтово адресиране е по същество устройство с ултра-бърз I/O, което трябва да бъде достъпно в потребителското пространство. Това изследване прави възможни нови подходи към микроядрата, екзоядрата и други традиционни опити за безопасно преместване на функционалност от ядрото на ОС към потребителското пространство. 

Владимир: Байт-адресируемата памет е страхотна, но има физическо ограничение - скоростта на светлината. Това означава, че неизбежно ще има забавяне при взаимодействие с устройството. 

Майкъл: Абсолютно прав.

Владимир: Ще има ли достатъчно капацитет за справяне с новите натоварвания?

Майкъл: Това е отличен въпрос, но ще ми е трудно да отговоря. Идеята за обработка в паметта съществува от доста време, много е интересна, но и много сложна. Не съм работил в тази област, но би било чудесно, ако там се направят някои открития. Страхувам се, че няма какво повече да добавя. 

Владимир: Има още един проблем. Нови, значително по-големи количества RAM ще бъде невъзможно да се поберат в процесора. Следователно, поради физически ограничения, тази RAM трябва да бъде изолирана. 

Майкъл: Всичко зависи от броя на дефектите в производството на интегрални схеми. Ако беше възможно да се създадат полупроводникови пластини изцяло без дефекти, тогава би било възможно да се направи цяла микросхема от тях. Но сега не знаем как да направим микросхеми, по-големи от пощенските марки. 

Владимир: Но все пак говорим за огромни размери, за сантиметри. Това неизбежно оказва влияние върху латентността. 

Майкъл: Да. Не можете да направите нищо за скоростта на светлината. 

Владимир: За жалост. 

Следващата голяма тенденция. Двойни структури от данни. Хидра.

Виталий: Доколкото разбрах, много бързо улавяш новите тенденции. Вие бяхте един от първите, които работеха с транзакционна памет и един от първите, които работеха с енергонезависима памет. Каква според вас ще бъде следващата голяма тенденция? Или може би е тайна?

Майкъл: Честно казано, не знам. Надявам се, че ще мога да забележа, когато се появи нещо ново. Нямах достатъчно късмет да измисля нова област сам, но имах малко късмет и успях да започна да работя доста рано в нови области, създадени от други. Надявам се, че ще мога да правя това в бъдеще.

Алекс: Последният въпрос в това интервю ще бъде относно представянето ви в Hydra и дейностите ви в училище. Ако разбирам правилно, докладът в училището ще бъде за алгоритми без блокиране, а на конференцията за двойни структури от данни. Бихте ли казали няколко думи за тези доклади?

Майкъл: Отчасти вече засегнахме тези теми с вас в това интервю. Става въпрос за работата, която свърших с моя ученик Бил Шерер. Той написа дисертация върху него и Дъг Лий също допринесе за него и в крайна сметка той стана част от многонишковите синхронни опашки в библиотеката на Java. Да приемем, че структурата на данните се чете и записва без блокиране, тоест всяка операция има ограничен брой инструкции по критичния път. Ако се опитате да премахнете данни от празен контейнер или се опитате да премахнете определени данни, които не са в този контейнер, веднага ще бъдете информирани, че това не може да бъде направено. Но това поведение може да не е приемливо, ако нишката наистина се нуждае от тези данни. Тогава първото нещо, което идва на ум, е да създадете цикъл, който постоянно ще пита дали са се появили необходимите данни. Но тогава има намеса за всички останали. Освен това с този подход можете да изчакате 10 минути и след това ще дойде друга нишка и тя случайно първо ще получи необходимите данни. Двойните структури от данни все още нямат ключалки, но позволяват на нишките да чакат правилно. Терминът "двойно" означава, че структурата съдържа или данни, или заявки за данни, нека ги наречем анти-данни. Така че, ако се опитате да извлечете нещо от празен контейнер, вместо това в контейнера ще бъде поставена заявка. Сега нишката може да чака заявка, без да безпокои никой друг. Освен това структурата на данните присвоява приоритети на заявките, така че когато бъдат получени, да ги предава на правилния човек. Резултатът е незаключващ механизъм, който все още има формална спецификация и добро представяне на практика. 

Алекс: Какви са вашите очаквания от тази структура от данни? Ще подобри ли производителността във всички обичайни случаи или е по-подходящ за определени ситуации? 

Майкъл: Полезно е, ако, първо, имате нужда от контейнер без заключване, и, второ, трябва да изчакате в ситуация, в която трябва да извлечете данни от контейнера, който не е в него. Доколкото ми е известно, нашата рамка осигурява оптимално поведение, когато тези две условия са изпълнени. Затова в тези случаи препоръчвам да го използвате. Основното предимство на структурите от данни без заключване е, че избягват проблеми с производителността. И чакането е много важно в много алгоритми, ако данните се прехвърлят от една нишка към друга.

Виталий: Нека поясня: ще говорите ли за едно и също нещо и в училище, и на конференцията?

Майкъл: В училище Аз ще говоря общо за многонишковите структури от данни, като основните принципи са описани в началото на урока. Предполагам, че публиката знае какво представляват нишките и е запозната с ключалките. Въз основа на това основно знание ще говоря за структури от данни без заключване. Ще направя преглед на най-важните проблеми в тази област, засягайки теми като управление на паметта. Не мисля, че ще има нещо по-сложно от MS queue.

Алекс: Планирате ли да преподавате за двойни структури от данни в края на вашия клас в училище?

Майкъл: Ще ги спомена, но няма да им отделям много време. На тях ще бъде посветен репортажът на Hydra. Той ще обхване проекта, който в крайна сметка стигна до Java, както и работата с Джо Израелевич за създаване на двоен вариант на опашката LCRQ и създаване на почти универсален дизайн за двойни структури от данни.

Алекс: Значи лекцията в училище може да се препоръча за начинаещи, а лекцията за двойни структури от данни на Hydra - за хора, които вече имат известен опит?

Майкъл: Поправете ме, ако греша, но публиката в Hydra ще бъде доста разнообразна, включително много експерти по Java и като цяло хора, които не се занимават конкретно с многопоточно програмиране. 

Виталий: Да, това е вярно.

Алекс: Поне се надяваме.

Майкъл: В този случай ще се изправя пред същия проблем, с който започнахме това интервю: как да направим репортаж, едновременно достатъчно богат на технически подробности и достъпен за всички слушатели.

Виталий: Ще изнесете ли доклад по същия начин, по който изнасяте лекции? Тоест да говорите с публиката и да се адаптирате към ситуацията?

Майкъл: Опасявам се, че няма да се получи така, защото докладът ще бъде със слайдове. Слайдовете са важни, когато слушателите първоначално говорят различни езици. На много хора ще им е трудно да ме разберат на английски, особено ако говоря твърде бързо. Избрах тези теми, защото Петър Кузнецов ме помоли да говоря за структури от данни без заключване в SPTDC School; и след това имах нужда от доклад за конференция на Java потребителска група и исках да избера нещо, което би представлявало интерес специално за Java програмистите. Най-лесният начин беше да говоря за онези неща в библиотеката на Java, с които имах ръка по един или друг начин. 

Алекс: Предполагаме, че аудиторията на Hydra вече знае нещо за програмирането без заключване и може би има известен опит в тази област. Но това е само предположение, ситуацията ще стане по-ясна на самата конференция. Както и да е, благодаря за отделеното време. Сигурен съм, че интервюто ще бъде много интересно за нашите читатели. Благодаря много!

Виталий: Благодаря ти. 

Майкъл: Ще се радвам да се срещнем в Санкт Петербург. 

Алекс: Ние също имаме красив град. Някога бил ли си тук?

Майкъл: Не, никога не съм бил в Русия. Но Санкт Петербург винаги е бил в списъка с места, където още не съм бил, но където наистина искам да отида, така че много се зарадвах на поканата. 

Алекс: Между другото, ще имаме програма от екскурзии за лекторите. Благодаря ви много за интервюто и хубав ден!

Можете да продължите разговора си с Майкъл на конференцията Hydra 2019, която ще се проведе на 11-12 юли 2019 г. в Санкт Петербург. Той ще дойде с доклад „Двойни структури от данни“. Билети могат да бъдат закупени на официалния уебсайт.

Източник: www.habr.com