- як професор Computer Science у Рочестерському університеті, а у рідному університеті Wisconsin-Madison був деканом протягом п'яти років. Він займається дослідженнями в галузі паралельного та розподіленого програмування та дизайну мов та навчає цьому студентів.
Світ знає Майкла за підручником , а робота отримала премію Дейкстри як одне з найвідоміших у сфері розподілених обчислень. Також ви можете знати його як автора того самого алгоритму .
Разом із Дагом Лі розробив ті неблокуючі алгоритми та синхронні черги, на яких працюють бібліотеки Java. Впровадження JavaSE 6 дозволило в 10 разів поліпшити продуктивність ThreadPoolExecutor.
Зміст:
- Початок кар'єри, Рочестерський університет. Проект Charlotte, мова Lynx;
- IEEE Scalable Coherent Interface, блокування MCS;
- Виживання в постійно мінливому світі;
- Чи стають студенти дурнішими? Глобальні тренди, інтернаціоналізація;
- Ефективна робота із студентами;
- Як не відстати під час підготовки нових курсів та книг;
- Зв'язок між бізнесом та академією;
- Практична реалізація ідей. MCS, MS, CLH, JSR 166, робота з Дагом Лі та багато іншого;
- Транзакційна пам'ять;
- Нові архітектури. Близька перемога транзакційної пам'яті;
- Енергонезалежна пам'ять, Optane DIMM, надшвидкі пристрої;
- Наступний великий тренд. Dual data structures. Hydra.
Інтерв'ю ведуть:
Віталій Аксьонов - на даний момент пост-док в IST Austria та співробітник кафедри "Комп'ютерні Технології" Університету ІТМО. Займається дослідженнями у сфері теорії та практики конкурентних структур даних. До роботи в IST, він отримав PhD в Університеті Париж Дідро та в Університеті ІТМО під керівництвом професора Петра Кузнєцова.
Олексій Федоров — продюсер JUG Ru Group, російської компанії, яка займається організацією конференцій для розробників. Олексій брав участь у підготовці більш ніж 50 конференцій, а в його резюме є все що завгодно, починаючи від позиції інженера-розробника Oracle (JCK, Java Platform Group), і закінчуючи позицією деврела в компанії Однокласники.
Володимир Ситніков - Інженер в компанії Netcracker. Десять років працює над продуктивністю та масштабованістю NetCracker OS - ПЗ, що використовується операторами зв'язку для автоматизації процесів управління мережею та мережевим обладнанням. Захоплюється питаннями продуктивності Java та Oracle Database. Автор понад десяток покращень продуктивності в офіційному PostgreSQL JDBC-драйвері.
Початок кар'єри, Рочестерський університет. Проект Charlotte, мова Lynx.
Олексій: Для початку я хотів розповісти вам, що ми в Росії все дуже любимо Сomputer Science, Data Science та алгоритми Прямо до непристойності. Ми всі читали . Тому майбутня конференція, школа та саме це інтерв'ю мають користуватися великою популярністю. Нам надійшло безліч питань для цього інтерв'ю від студентів, програмістів та членів спільноти, тому ми дуже вдячні вам за цю можливість. Чи користується Computer Science такою самою любов'ю у США?
Майкл: Наша область настільки різнобічна, в ній так багато напрямків, і вона впливає на суспільство такими різними способами, що мені важко відповісти вам однозначно. Але факт у тому, що завдяки їй за останні 30 років відбулися колосальні зміни у бізнесі, промисловості, мистецтві та суспільстві загалом.
Віталій: Давайте почнемо з чогось віддаленого У багатьох університетах спостерігається щось подібне до спеціалізації на одному певному напрямку. Для університету Карнегі-Меллона це паралельні обчислення, для MIT – криптографія, роботи та багатопоточність. А чи є подібна спеціалізація в Рочестерському університеті?
Майкл: Якщо чесно, я б сказав, що CMU та MIT спеціалізуються по всіх напрямках На нашій кафедрі завжди найбільше уваги приділялося штучному інтелекту. Половина людей, які у нас працюють, займаються ІІ або людино-комп'ютерною взаємодією — ця частка більша, ніж на інших кафедрах, і так було завжди. Але коли я навчався в університеті, у мене не було курсів з ІІ, і я ніколи в цій галузі не працював. Тож моя кафедра спеціалізується на проблемі, до якої я не маю стосунків. Втіхою є те, що друга за важливістю для нашої кафедри проблема — це паралельне та багатопоточне програмування, тобто моя спеціалізація.
Віталій: Ви почали займатися Computer Science, коли область багатопотокового програмування тільки зароджувалася. За списком ваших публікацій видно, що перші роботи стосувалися досить широкого спектра питань: керування пам'яттю в багатопотокових системах, розподілені файлові системи, операційні системи. Чому така різнобічність? Ви намагалися знайти своє місце у дослідницькій спільноті?
Майкл: Будучи студентом, я брав участь у в університеті Вісконсіна, в рамках якого розроблялася одна з перших розподілених операційних систем. Там я працював разом із Рафаелем Фінкелем () та Марвіном Соломоном (). Моя дисертація була присвячена розробці мови для системного софту для розподілених систем — зараз про неї вже всі забули, і слава богу. Я створив мову програмування Lynx, яка мала спростити створення серверів для розподіленої операційної системи зі слабким зв'язуванням. Оскільки на той момент я в основному займався операційними системами, то припускав, що моя кар'єра буде пов'язана з ними. Але у Рочестері університет був дуже маленький, і через це різні групи там дуже тісно спілкувалися один з одним. Там не було десятка інших фахівців з операційних систем, з якими я міг би спілкуватися, тому всі контакти були з людьми, які працювали в зовсім інших областях. Мені це дуже подобалося бути універсалом — велика перевага для мене. Якщо ж говорити конкретно про багатопотокові структури даних та алгоритми синхронізації, то ними я почав займатися зовсім випадково.
IEEE Scalable Coherent Interface, блокування MCS.
Віталій: Чи можна трохи докладніше про це?
Майкл: Це кумедна історія, яку я не втомлююся всім розповідати Вона відбулася на конференції у Бостоні — це було наприкінці 80-х чи на початку 90-х. На конференції був присутній Джон Меллор-Краммі (), випускник нашого факультету. Я був із ним знайомий, але ми до цього не вели спільних досліджень. Мері Вернон () з Вісконсіну виступала з доповіддю про багатопроцесорну систему, яку вони розробляли у Вісконсіні: . У цьому Multicube на рівні заліза був механізм синхронізації, який називався Q on Sync Bit, а пізніше він був перейменований на Q on Lock Bit, тому що так його можна було вимовляти як назву сиру Colby, тобто це був такий каламбур. Якщо ви цікавитеся механізмами багатопоточності, ви, напевно, знаєте, що Colby врешті-решт став механізмом синхронізації стандарту Scalable Coherent Interface від IEEE. Це був механізм блокування, який створював покажчики з одного кешу на інший на рівні заліза, щоб кожен власник блокування знав, чия черга за ним. Коли Джон і я про це почули, ми переглянулись і сказали: а навіщо це робити на рівні заліза? Хіба не можна того ж таки добитися за допомогою compare-and-swap? Ми взяли один із блокнотів, що лежали в аудиторії, і накидали на ньому поки Мері продовжувала свою доповідь. Згодом ми її реалізували, поекспериментували, ідея виявилася вдалою і ми опублікували статтю. Тоді для мене ця тема здавалася лише смішним відволіканням, після якого я планував повернутися до операційних систем. Але потім виникла інша проблема в тому ж напрямку, і зрештою синхронізація, багатопоточність та структури даних стали моєю основною спеціальністю. Як бачите, сталося це все випадково.
Віталій: Я давно знайомий із блокуванням MCS, але до поточного моменту я не знав, що це Ваша робота, і не розумів, що це акронім від Ваших прізвищ.
Як виживати в світі, що постійно змінюється?
Олексій: У мене є питання з пов'язаної теми 30 чи 40 років тому було більше свободи у різних спеціальностях. Хочеш розпочати кар'єру в багатопоточності чи розподілених системах – будь ласка, хочеш зайнятися операційними системами – жодних проблем. У кожній області було дуже багато відкритих питань та мало експертів. Зараз з'явилися вузькі спеціалізації: немає просто експертів з операційних систем загалом, є фахівці з окремих систем. Те саме з багатопоточністю та розподіленими системами. Але проблема в тому, що наші життя не є нескінченними, кожен може присвятити дослідженням лише кілька десятиліть. Як вижити у цьому новому світі?
Майкл: Ми в цьому плані не особливі, все те саме відбувалося колись і в інших областях Мені пощастило, що я почав працювати в Computer Science, коли ця сфера була у підлітковому віці. Деякі основи вже були закладені, але все ще дуже незріле. Така можливість виникає нечасто. Електротехніка існує вже дуже давно, фізика ще довше, математика мало не з початку часу. Але це означає, що у математиці ніхто більше робить цікавих відкриттів. Відкритих проблем, як і раніше, безліч, але в той же час і вчитися потрібно більше. Ви вірно помітили, що зараз значно більше спеціалізацій, ніж було раніше, але це лише означає, що ми опинилися в тій самій ситуації, що більшість інших галузей людської діяльності.
Олексій: Мене тут цікавить більш практичний аспект питання У мене математична освіта, і під час навчання я часто відвідував конференції та працював над різноманітними науковими темами. Я виявив, що мої доповіді ніхто в аудиторії не розумів, і так само, доповіді інших людей були зрозумілі тільки для них самих. У високорівневих темах це не так, але як тільки починаєш у щось заглиблюватися, аудиторія за тобою перестає встигати. Як ви з цим боретеся?
Майкл: Не завжди успішно Нещодавно я підготував доповідь, в якій пішов надто глибоко в технічні подробиці. Під час доповіді стало видно, що більшість аудиторії мене не розуміє, так що мені довелося пристосовуватися до ситуації на ходу. Слайди було вже не змінити, тож вийшло не надто вдало — тому взагалі кажучи, я намагаюся слайди не використовувати. Загалом моя порада така — враховуйте свою аудиторію. Потрібно знати, до кого ви звертаєтесь, який у них рівень знань і що їм потрібно почути, щоби оцінити вашу роботу.
Віталій: А ви не могли б натякнути, про що була ця лекція?
Майкл: Якщо чесно, я хотів би на цю тему не поширюватися, щоб залишити анонімними тих людей, про яких йдеться Суть у тому, що ми часто занурюємося надто глибоко у тонкощі тієї проблеми, над якою працюємо, тому нам важко пояснити на початку доповіді, чому ця проблема цікава і важлива і як вона пов'язана з питаннями, які слухачі вже знають. За моїми спостереженнями, студентам ця навичка дається найважче. І це ж було слабкою стороною моєї недавньої доповіді. Правильно побудована доповідь має з самого початку знайти контакт з аудиторією, пояснити їй, у чому саме полягає проблема і як вона співвідноситься з відомими їй темами. Наскільки технічною буде ця вступна частина, залежить від аудиторії. Якщо вона зовсім різношерста, то доповідь може бути багатоступінчастою. Вступ має бути доступним усім, а до кінця частина, можливо, вже не встигатиме за вами, але люди, відносно знайомі з вашою областю, зможуть розібратися у всьому.
Чи стають студенти дурнішими? Глобальні тренди, інтернаціоналізація.
Олексій: Ви спостерігаєте за студентами вже кілька десятків років Чи стають студенти дурнішими або розумнішими від десятиліття до десятиліття або від року до року? У Росії професори постійно скаржаться, що студенти з кожним роком дурнішають, і незрозуміло, що з цим робити.
Майкл: Від нас, старих людей, дійсно можна почути багато негативу Підсвідомо ми маємо схильність очікувати, що студенти освоїть увесь той 30-річний досвід, який вже є у нас. Якщо я маю більш глибоке розуміння, ніж у 1985 році, то чому його немає у студентів? Напевно, бо їм 20 років, як вам таке? Думаю, найістотніші зміни в останні десятиліття стосуються демографічного складу: у нас зараз значно більше за міжнародних студентів, за винятком канадців. Раніше канадців було багато, оскільки ми дуже близько до кордону з Канадою, і студенти звідти можуть їздити додому на вихідних. Але зараз у Канаді багато хороших університетів, і канадці вважають за краще вчитися у себе, у США їх почало їздити значно менше.
Олексій: Як ви думаєте, це місцевий тренд чи глобальний?
Майкл: Не пам'ятаю точно хто, але хтось сказав, що світ плоский Наша область стала значно більш міжнародною. раніше проходили виключно всередині США, потім вирішили раз на чотири роки проводити їх в інших країнах, а зараз вони проходять по всьому світу. Ще більшою мірою ці зміни торкнулися оскільки вона завжди була більш міжнародною організацією, ніж ACM. А керівники програм (program chairs) є з Китаю, Індії, Росії, Німеччини та багатьох інших країн, бо скрізь зараз багато чого відбувається.
Олексій: Але, ймовірно, є якісь негативні сторони такої інтернаціоналізації?
Майкл: Я б сказав, що всі негативні сторони стосуються не техніки, а політики Колись головною проблемою був той факт, що США крали найрозумніших та найталановитіших людей у країн у всьому світі. А зараз основна проблема — це політичні ігри між різними країнами навколо віз та імміграції.
Олексій: Тобто бар'єри тощо. Зрозуміло.
Володимир: Особисто мені цікаво, якого підходу ви дотримуєтеся, коли викладаєте новий предмет студентам Адже є різні варіанти: можна намагатися в першу чергу надихнути їх спробувати щось нове, а можна більше уваги приділяти подробицям того, як влаштована певна технологія. Що ви віддаєте перевагу?
Ефективна робота зі студентами
Олексій: І як знайти чортовий баланс між першим і другим?
Майкл: Проблема в тому, що заняття не завжди відбуваються так, як мені хотілося б Зазвичай я заздалегідь даю студентам матеріал для читання, щоб вони в нього вникли, щонайменше розібралися і сформулювали питання по тих місцях, які зрозуміти не вдалося. Тоді у класі можна зосередитися саме на найважчих моментах та дослідити їх усім разом. Це те, як мені найбільше подобається вести заняття. Але з урахуванням того навантаження, яке зараз лежить на студентах, мені далеко не завжди вдається зробити так, щоб вони підготувалися заздалегідь. У результаті доводиться приділяти загальному переказу матеріалу значно більше часу, ніж хотілося б. Незважаючи на це, я намагаюся, щоб наші заняття були інтерактивними. В іншому випадку простіше один раз записати відео, яке студенти можуть дивитися у себе вдома. Сенс живих занять – у людській взаємодії. На заняттях я волію користуватися не слайдами, а крейдою та дошкою, за винятком окремих випадків, коли якась діаграма надто складна, щоб її зобразити на дошці. Завдяки цьому мені немає необхідності дотримуватись жорсткого плану заняття. Оскільки немає чітко визначеного порядку, в якому я даю матеріал, це дозволяє адаптуватися до аудиторії залежно від питань, які я отримую. Загалом, я намагаюся, щоб заняття були якомога інтерактивнішими, щоб викладений мною матеріал залежав від питань, які мені ставлять.
Володимир: Це дуже здорово. На мій досвід досить складно добитися від слухачів питань. Навіть якщо заздалегідь просиш ставити будь-які питання, не важливо, дурні чи розумні, вони все одно мовчать. Як ви з цим справляєтесь?
Майкл: Ви будете сміятися, але якщо досить довго мовчки стояти, то рано чи пізно всім стане незручно, і хтось нехай поставить питання. Або можна поставити просте технічне питання з відповіддю «так» чи «ні», щоб визначити, чи зрозуміли люди, про що щойно йшлося. Наприклад, чи є у наведеному прикладі гонка даних? Хто вважає, що так? Хто вважає, що ні? Хто взагалі нічого не розуміє, бо загалом піднялася лише половина рук?
Віталій: І якщо ти відповів невірно, вилітаєш із класу 🙂
Майкл: Якщо ти не відповів нічого, то маєш поставити запитання Я маю зрозуміти, що саме студенту потрібно знати, щоб відповісти на запитання, яке я щойно поставив. Потрібно, щоб вони допомогли мені допомогти їм. Я готовий підлаштуватись під них, щоб вони розібралися в проблемі. Але якщо я не знаю, що відбувається у них у голові, я не можу цього зробити. І якщо досить довго не давати студентам спокою, то врешті-решт вони задають правильні питання, тобто такі, завдяки яким я бачу, що саме відбувається в головах у студентів.
Олексій: Чи наголошують іноді ці питання на ідеї, про які ви самі раніше не думали? Чи бувають вони несподіваними? Чи дозволяють глянути на якусь проблему в новому світлі?
Майкл: Бувають питання, завдяки яким відкривається новий спосіб подачі матеріалу Часто бувають питання, що призводять до цікавих проблем, про які я не планував говорити. Студенти мені часто кажуть, що у мене є схильність уникати теми заняття, коли таке відбувається. І, згідно з ними, дуже часто це буває найцікавіша частина заняття. Дуже рідко, буквально кілька разів, студенти ставили питання, які наштовхували на новий напрямок у дослідженні та виростали до статті. Це значно частіше відбувається у розмовах зі студентами, а не під час занять, але зрідка було й під час занять.
Олексій: Тобто студенти ставили вам питання, на основі яких потім можна було опублікувати статтю?
Майкл: Так
Віталій: Наскільки часто у вас відбуваються такі бесіди зі студентами? Коли вони хочуть дізнатись більше, ніж було розказано під час заняття?
Майкл: З моїми аспірантами - постійно У мене їх десь 5 чи 6 людей, і ми постійно з ними щось обговорюємо. А розмови такого роду зі студентами, які просто відвідують мої заняття, не надто часто. Хоча хотілося б, щоби це відбувалося частіше. Підозрюю, що вони просто бояться приходити на факультет у години прийому. Кожен семестр деяким студентам вдається подолати психологічний бар'єр, і з ними завжди дуже цікаво говорити після занять. Щоправда, якби всі студенти були настільки сміливими, у мене просто не вистачило б часу. Отже, можливо, все працює так, як треба.
Віталій: Як вам вдається знаходити час для спілкування зі студентами? Наскільки я знаю, у США викладачі мають дуже багато роботи — заявки на гранти тощо.
Майкл: Чесно кажучи, робота зі студентами — це той аспект моєї діяльності, який мені подобається найбільше Тож мотивації до цього в мене достатньо. Більшість часу, яке я проводжу у своєму офісі, йде на всілякі зустрічі. Наразі літо, тому графік менш щільний, але під час навчального року щодня з 9 до 17 у мене все забито. Дослідницька робота, рецензії, гранти — для цього залишаються лише вечори та вихідні.
Як не відстати під час підготовки нових курсів та книг.
Олексій: Чи продовжуєте ви зараз читати якісь курси, які ви читаєте протягом тривалого часу? Щось на кшталт введення в Computer Science.
Майкл: Перше, що тут спадає на думку — курс мов програмування
Олексій: Наскільки сильно відрізняється сьогоднішній варіант цього курсу від того, який був 10, 20, 30 років тому? Можливо, тут цікавішими не подробиці окремого курсу, а загальні тенденції.
Майкл: Мій курс мов програмування був дещо незвичайний у той час, коли я його створив Я почав читати його в кінці 1980-х, замінивши мого колегу, Дага Болдуїна (). Тема курсу лише опосередковано ставилася до моєї спеціалізації, але коли він пішов, я виявився найкращим кандидатом для цього курсу. Мені не подобався жоден із існуючих підручників, тому я зрештою сам написав підручник для цього курсу. (Примітка редакції: йдеться про книгу) Зараз він використовується у більш ніж 200 університетах по всьому світу. Мій підхід незвичайний у тому плані, що в ньому свідомо поєднуються проблеми проектування мови та її реалізації, і велика увага приділяється взаємодії між цими аспектами у всіх можливих галузях. Основний підхід залишився незмінним, як і багато базових понять: абстракції, простір імен, модульність, типи. А ось набір мов, за допомогою якого ці поняття демонструються, помінявся цілком. Коли курс був тільки створений, в ньому було безліч прикладів Pascal, а сьогодні багато моїх студентів про таку мову навіть не чули. Зате вони знають Swift, Go, Rust, тому я маю говорити про мови, які в ходу сьогодні. Крім того, зараз студенти добре розуміються на скриптових мовах, а коли я починав викладати цей курс, він цілком був присвячений мовам, що компілюються. Зараз потрібно багато матеріалу про Python, Ruby і навіть Perl, тому що це те, на чому в наші дні пишуть код, в цих мовах відбувається безліч цікавих речей, у тому числі в галузі проектування мов.
Віталій: Тоді моє наступне питання буде пов'язане з попереднім Як не відстати у цій галузі? Я підозрюю, що оновлювати такий курс потребує великого обсягу роботи — треба розумітися на нових мовах, розуміти основні ідеї. Як вам це вдається?
Майкл: Я не можу похвалитися, що у мене це завжди на 100% виходить Але найчастіше я просто роблю те, що роблять решта — читаю інтернет. Якщо я хочу розібратися в Rust, я вбиваю його в Google, йду на сторінку Mozilla і читаю викладене керівництво. Це щодо речей, що відбуваються в комерційній розробці. Якщо ж говорити про науку, то тут слід слідкувати за доповідями на головних конференціях.
Зв'язок між бізнесом та академією
Віталій: Давайте поговоримо про зв'язок між бізнесом та науковими дослідженнями У списку ваших робіт я знайшов кілька статей про узгодженість кешу (cache coherence). Наскільки я розумію, під час їхньої публікації алгоритми узгодженості кешу були нестабільними? Або недостатньо поширеними. Наскільки загальноприйнятими були ваші ідеї на практиці?
Майкл: Я точно не впевнений, про які саме публікації ви говорите Я досить багато роботи зробив з моїми студентами Біллом Болоскі () і Леонідасом Контотанассісом () на початку 1990-х над керуванням пам'яттю машин Неймана. У той час у бізнесі ще не було розуміння того, як правильно зробити багатопроцесорну систему: чи варто створювати підтримку доступу до віддаленої пам'яті на рівні заліза, чи варто робити розподілену пам'ять, чи можна виконувати завантаження кеша з віддаленої пам'яті, або необхідно переміщувати сторінки в операційній системі. Білл і Леонідас обидва працювали в цій галузі та досліджували підходи без віддаленого завантаження кешу. Це безпосередньо не відносилося до узгодженості кешу, але все ж таки це була робота над управлінням пам'яттю NUMA, і згодом з цього зросли сучасні підходи до page placement у сучасних операційних системах. Загалом, Білл і Леонідас виконали важливу роботу, хоча й не найвпливовішу в цій галузі — тоді над цим працювало багато інших людей. Пізніше я займався темою, пов'язаною із узгодженістю кеша в контексті апаратної транзакційної пам'яті (hardware transactional memory). Група, разом з якою я працював над цією проблемою, отримала кілька патентів. За ними стоять досить цікаві ідеї, але я не думаю, що вони зрештою отримають практичну реалізацію. Так чи інакше, мені складно судити про їхню прибутковість.
Олексій: У цьому зв'язку особисте питання: наскільки для вас важливо, щоб ваші ідеї були реалізовані на практиці? Чи ви не думаєте про це?
Майкл: Я люблю ставити це питання в інтерв'ю з іншими людьми, абітурієнтами чи кандидатами, які бажають працювати на факультеті Мені не здається, що на це питання є правильна відповідь. У людей, які роблять класні речі, може бути різна мотивація. Мене проблеми залучають, тому що вони особисто мені здаються цікавими, а не через їхню практичну користь. Але з іншого боку, коли якась цікава штука таки знаходить собі застосування, мені це дуже подобається. Тож тут все непросто. Але на початку роботи все-таки мною рухає не ідея кінцевого використання у світі, а стрункість ідеї та бажання її дослідити та подивитися, що з неї вийде. Якщо в результаті вона дасть практичну віддачу - добре.
Олексій: Завдяки вашій освіті та досвіду ви краще за багатьох здатні оцінити цінність чужих ідей. Ви можете порівняти їх та визначити, що з чим краще працює. Я впевнений, що у вас є думка про речі, які зараз використовуються на практиці великими виробниками на зразок Intel. Наскільки на ваш погляд правильний курс, яким йдуть ці компанії?
Майкл: Практика завжди обертається навколо того, що може мати комерційний успіх, тобто створювати прибуток, і про це вам краще запитати когось іншого Моя робота в основному закінчується публікаціями, а в галузі операційних систем вони оцінюються за показниками продуктивності: швидкість, споживання енергії, розмір коду. Але мені завжди здавалося, що ці емпіричні результати додаються до статей лише для того, щоб їх можна було опублікувати, а реальні мотиви для роботи у людей естетичні. Дослідники оцінюють рішення з художнього боку, їм важливо, наскільки ідеї елегантні, і намагаються створити щось краще, ніж вже існуючі підходи. Дослідниками рухають особисті, суб'єктивні, естетичні мотиви. Але у самій статті про це не напишеш, для програмного комітету ці речі не є аргументами. На щастя, елегантні рішення найчастіше також виявляються швидкими та дешевими. Ми разом із десятком моїх колег обговорювали цю тему десь 15 років тому і зрештою написали написали про це статтю. Думаю, зараз її ще можна знайти, вона називається або щось таке, у неї більше десятка авторів. Це єдина стаття, в якій я автор разом із Так що якщо ви зробите пошук її імені в моєму списку публікацій, то знайдете те, що потрібно. Там йдеться про оцінку досліджень систем та про те, наскільки важлива елегантність.
Олексій: Тобто між стандартом того, що вважається хорошим результатом у науці та у бізнесі, існує різниця У науці оцінюється продуктивність, енергоспоживання, TDP, простота реалізації та багато іншого. Чи є у вас можливість вести такі дослідження в університеті? Чи є у вас лабораторія з різними машинами та різними архітектурами, в якій можна було ставити експерименти?
Майкл: Так, у нашої кафедри дуже багато різних цікавих машин Найчастіше вони маленькі, ми маємо невеликий кластер і багато багатопроцесорних систем з різними прискорювачами. Крім того, на кампусі є величезний обчислювальний центр, який обслуговує вчених із кількох десятків різних дисциплін. У ньому близько тисячі вузлів та двадцяти тисяч ядер, все на Linux. Якщо виникає потреба, завжди можна купити трохи AWS. Тож із залізом у нас суттєвих обмежень немає.
Олексій: А як було тридцять років тому? Тоді проблеми були?
Майкл: Тоді було дещо інакше У середині-кінці 1980-х вважалося, що науці не вистачає обчислювальних ресурсів. Щоб виправити цю ситуацію, Національний науковий фонд ) створив програму координованих експериментальних досліджень (Coordinated Experimental Research, CER). Завданням цієї програми було надати обчислювальну інфраструктуру для кафедр Computer Science, і вона досягла істотних змін. На надані нею гроші ми в Рочестерському університеті купили в 1984 128-вузловий BBN Butterfly, це було за рік до моєї появи там. На той момент це була найбільша у світі багатопроцесорна система із загальною пам'яттю. Вона мала 128 процесорів, кожен на окремій материнській платі, вона займала чотири стійки. Кожен процесор мав мегабайт пам'яті, 128 мегабайт оперативної пам'яті на той час було неймовірною кількістю. На цій машині ми вперше реалізували блокування MCS.
Олексій: Тобто якщо я правильно вас зрозумів, то на даний момент проблему із залізом вирішено?
Майкл: Загалом і в цілому - так Є кілька застережень: по-перше, якщо ви займаєтеся архітектурою комп'ютера на рівні мікросхем, то в академічному середовищі це робити складно, оскільки в бізнесі для цього є набагато досконаліші інструменти. Якщо вам потрібно щось менше 10 нанометрів, то це доведеться замовляти у когось на стороні. У цій галузі значно простіше бути дослідником у Intel. Якщо ви працюєте над оптичними зв'язками на чіпах або над твердотільною пам'яттю, то ви знайдете в бізнесі технології, яких поки що немає в науці, так що доводиться створювати спілки. Наприклад, Стівен Свансон () створив для нових технологій пам'яті Ця форма не завжди працює, але в деяких випадках вона може бути успішною. З іншого боку, у науці важче йде розвиток найпотужніших обчислювальних систем. Наймасштабніші проекти із суперкомп'ютерами, які зараз є у США, Японії та Китаї, усі зосереджені у бізнесі.
Практична реалізація ідей. MCS, MS, CLH, JSR 166, робота з Дагом Лі та багато іншого.
Віталій: Ви вже розповіли про те, як почали працювати над алгоритмами синхронізації У вас є дві дуже відомі статті про и , які у певному сенсі були реалізовані в Java. (Примітка редакції: всі публікації можна переглянути ). Там це блокування було реалізовано з деякими змінами і вийшло , А черга була реалізована як і замислювалася. Але між публікацією ваших статей та їх практичним застосуванням минуло багато років.
Олексій: Здається, близько 10 років у випадку з чергою
Майкл: Перш ніж ці фічі з'явилися в стандартній бібліотеці Java?
Віталій: Так Що ви зробили, щоб це сталося? Чи нічого не робили?
Майкл: Я можу розповісти вам, як черга MS потрапила в Java 5. За кілька років до її появи я працював із групою Марка Мойєрса (Mark Moyers) із Sun Microsystems у їхній лабораторії під Бостоном. Він організував семінар для своїх знайомих, які займалися цікавими проблемами у багатопотоковості, оскільки він хотів знайти теми, які можна було б продати їхній компанії. Там я вперше зустрів Дага Лі (Doug Lea). Даг, я і ще десь 25 інших людей із Sun разом обговорювали презентацію Дага про , що згодом став java.util.concurrent. Під час справи Даг сказав, що він хотів би використовувати чергу MS, але для цього йому був необхідний лічильник кількості елементів у черзі для інтерфейсу. Тобто це мав робити окремий метод, атомарний, точний та швидкий. Я запропонував просто додати серійні номери до вузлів, взяти номер першого вузла і останнього і забрати один від одного. Даг почухав голову, сказав «чому б і ні», і в результаті так і вчинив. Ми обговорювали з ним реалізацію цього підходу в бібліотеці, але більшість роботи Даг зробив сам. У результаті йому вдалося налагодити відмінну підтримку багатопоточності Java.
Олексій: Тобто якщо я правильно розумію, метод .size() повинен був входити до стандартного інтерфейсу черги, і у нього мала бути алгоритмічна складність O(1)?
Майкл: Так, і крім цього необхідний окремий лічильник
Олексій: Тому що якщо викликати метод .size() Java, очікується, що результат буде доступний відразу ж, а не залежно від реального розміру колекції. Зрозуміло, дякую.
Майкл: Декількома роками пізніше я працював над подвійними структурами даних (dual data structures) з моїм студентом Біллом Шерером (Bill Scherer) — власне, про них буде мій . Даг підійшов до нас і сказав, що вони стали б у нагоді йому в Java Executor Framework. Разом із Біллом вони створили дві реалізації, так звані чесні та нечесні черги (fair and unfair queues). Я консультував їх щодо цього проекту, хоч і не брав участі в написанні власне коду. У результаті швидкість executors значно збільшилася.
Володимир: Чи стикалися ви з невірними реалізаціями ваших алгоритмів чи з проханнями додати нові фічі? Загалом практика має збігатися з теорією, але досить часто вони відрізняються. Припустимо, ви написали алгоритм, і на папері він працює, але люди, які займаються реалізацією, стали просити у вас більше фіч або будь-якої настройки алгоритму. Чи були у вас такі ситуації?
Майкл: Єдиний приклад, в якому до мене підійшли і запитали «як реалізувати» - це питання Дага, про яке я вже розповідав Але було кілька випадків, коли відповідно до практичних потреб вносилися цікаві зміни. Наприклад, команда K42 з IBM конвертувала блокування MCS і зробила стандартний інтерфейс, завдяки якому не було необхідності передавати туди і назад вузол черги підпрограм acquire і release. Завдяки цьому стандартному інтерфейсу ідея, красива теоретично, стала працювати практично. Дивно, що вони так і не опублікували статтю, а патент хоч і отримали, але потім від нього відмовилися. Задум був чудовим, і я за можливості намагаюся про нього розповідати.
Були й інші випадки, коли люди вносили вдосконалення в опубліковані мною алгоритми. Наприклад, у черзі MS є двоетапний механізм установки, а це означало, що на критичному шляху черги було два CAS. На старих машинах CAS були досить дорогими. Останнім часом Intel та інші виробники непогано їх оптимізували, але колись це були інструкції із 30 циклами, тому більше однієї на критичному шляху мати було небажано. В результаті була розроблена чудова черга, яка була схожа на чергу MS, але мала лише одну атомарну операцію на критичному шляху. Це досягалося тому, що протягом певного проміжку часу операція могла зайняти O(n) часу, а чи не O(1). Це було малоймовірно, але можливо. Відбувалося це через те, що в певні моменти алгоритм здійснював обхід черги з початку до поточного положення в цій черзі. В цілому алгоритм вийшов дуже вдалий. Наскільки я знаю, він не дуже широко використовується, частково тому, що атомарні операції вимагають значно менше ресурсів, ніж раніше. Але ідея була чудова. Мені також дуже подобається робота Дейва Дайса (Dave Dice) з Oracle. Все, що він робить, дуже практичне, і він дуже спритно використовує залізо. Він доклав руку до значної частини NUMA-аware алгоритмів синхронізації та багатопотокових структур даних.
Володимир: Коли ви пишете алгоритми або вчите студентів, результат роботи видно не відразу Спільноті потрібен якийсь час, щоб ознайомитись, скажімо, з новою статтею. Новий алгоритм далеко ще не відразу знаходить собі застосування.
Майкл: Далеко на відразу зрозуміло, виявиться стаття значущою чи ні Думаю, було б цікаво провести дослідження статей, які вибороли нагороди на конференціях. Тобто подивитися на статті, які люди в програмних комітетах свого часу визнали найкращими. Потрібно спробувати порахувати за кількістю посилань та впливом на бізнес, наскільки ці статті справді виявилися впливовими через 10, 20, 25 років. Я маю сумнів, що між цими двома параметрами була б сильна кореляція. Вона не буде нульовою, але, швидше за все, вона буде значно слабшою, ніж хотілося б. Багато ідей протягом довгого часу залишаються незатребуваними, перш ніж набувають поширення. Наприклад, візьмемо транзакційну пам'ять. З моменту публікації початкової статті до того часу, коли люди справді почали створювати машини з нею, минуло понад 10 років. А до появи цієї пам'яті в комерційних продуктах — і всі 20. Дуже довго ніхто не звертав уваги на статтю, а потім різко зросла кількість посилань на неї. Наперед це передбачити було б складно. З іншого боку, іноді ідеї знаходять реалізацію відразу. Кілька років тому я написав статтю разом з Джо Ізраїлевичем (Joe Izraelevitz) для DISC, в якій було запропоновано нове формальне визначення правильності для персистентних структур даних, які могли б використовуватися після збою комп'ютера, що працює з ними. Стаття мені подобалася з самого початку, але вона виявилася значно популярнішою, ніж я очікував. Їй скористалося кілька різних груп, у результаті вона стала стандартним визначенням персистентних структур. Що, звісно, приємно.
Володимир: А чи є якісь прийоми, які ви використовуєте для оцінки? Чи намагаєтеся ви взагалі оцінювати свої статті, своїх студентів? У плані того, чи йде людина, яку ви навчали, у правильному напрямку.
Майкл: Як і всі, я більше уваги приділяю тому, чим займаюся в даний момент Знову ж таки, як і всі, я зрідка перевіряю Google Scholar і дивлюся, чи цитуються мої минулі статті, але це скоріше з цікавості. В основному я захоплений тим, що мої студенти роблять зараз. Що ж до оцінки поточної роботи, то частково тут працюють міркування естетики, що елегантно, що — ні. На повсякденному рівні велику роль грають відкриті питання. Наприклад, до мене приходить студент із графіком деяких результатів, і ми намагаємося зрозуміти, звідки взялася деяка дивна поведінка графіка. Загалом у нашій роботі ми постійно намагаємося розібратися в речах, які поки що не розуміємо.
Транзакційна пам'ять
Віталій: Може, трохи поговоримо про транзакційну пам'ять?
Майкл: Думаю, варто сказати хоча б трохи, тому що я вклав у це дуже багато зусиль Це тема, за якою я маю більше публікацій, ніж за будь-якою іншою. Але при цьому, як це не дивно, я весь час був дуже скептично налаштований по відношенню до транзакційної пам'яті. На мій погляд, (M. Herlihy, J. E. B. Moss) була опублікована раніше свого часу. На початку 1990-х вони припустили, що транзакційна пам'ять могла б допомогти талановитим програмістам, які працюють над багатопоточними структурами даних, щоб ці структури потім як бібліотеки могли б використовуватися звичайними програмістами. Тобто це була б підмога для Дагов Лі, які займаються своїми JSR 166. Але транзакційна пам'ять не призначалася для того, щоб зробити багатопотокове програмування простим. Адже її саме так стали сприймати на початку 2000-х, коли вона набула поширення. Її рекламували як спосіб вирішити проблему паралельного програмування. Цей підхід завжди здавався безнадійним. Транзакційна пам'ять могла лише спростити написання паралельних структур даних. Цього вона, як мені здається, досягла.
Про складність написання багатопотокового коду
Олексій: Дуже цікаво. Здається, є певний бар'єр між звичайними програмістами та тими, хто може писати багатопотоковий код. Минулого року я кілька разів спілкувався з людьми, які займалися реалізацією певного алгоритмічного фреймворку. Наприклад, з Мартіном Томсоном, а також із програмістами, які працюють над багатопотоковими бібліотеками. (Примітка редакції: Мартін Томпсон – дуже відомий розробник, він написав и . А ще у нього є на нашій конференції Joker 2015, відеозапис . Він же цю конференцію, теж достуна). За їхніми словами, головна складність у тому, щоб алгоритми були одночасно швидкими та простими у використанні. Тобто вони намагаються якраз подолати цей бар'єр та залучити якнайбільше людей у цю область. Що ви про це думаєте?
Майкл: Це головна проблема багатопоточності: як досягти високої продуктивності, не збільшуючи складності системи.
Олексій: Тому що коли вони намагаються уникнути складності, алгоритм стає менш універсальним
Майкл: Тут головне — правильно спроектовані абстракції Мені здається, що це взагалі головне для комп'ютерних систем, як області. Цей термін любить вживати Батлер Лемпсон (Butler Lampson), і нас він називає торговцями абстракціями. Простих технологій сьогодні немає. У процесорах, які ми використовуємо, по 10 мільярдів транзисторів про простоту тут мови бути не може. При цьому ISA значно простіша за процесор, оскільки ми дуже довго працювали над тим, щоб забезпечити для неї високу продуктивність і відносно простий інтерфейс. Але й із нею не все гладко. Та сама проблема з прискорювачами, які зараз з'являються на ринку. Виникають питання - як зробити правильний інтерфейс для GPU, механізм шифрування, стиснення, механізм перекодування, механізм лінійної алгебри або навіть гнучкішу FPGA. Як зробити інтерфейс, який забезпечить простоту використання інструменту та приховає складність? Не позбудеться її, а саме приховає від простого програміста.
Олексій: Я так розумію, що у нас є ще бар'єр у розумінні абстракцій Візьмемо модель пам'яті, на нашому етапі розвитку науки та техніки – це одна з головних абстракцій. Завдяки їй усі програмісти діляться на дві групи: більша частина – це ті, хто її не розуміють, і менша – ті, хто розуміють, або думають, що розуміють.
Майкл: Це хороше питання — чи дійсно хтось із нас розуміє модель пам'яті
Віталій: Особливо C++
Майкл: Поговоріть якось з Гансом Бьомом (Hans Boehm) Це один із найрозумніших людей, яких я знаю, провідний експерт з моделей пам'яті. Він вам одразу скаже, що він дуже багато там не розуміє. Але якщо повертатися до питання абстракцій, то, як на мене, найважливіша думка в галузі моделей пам'яті за останні 30 років була висловлена . (Примітка редакції: повний список публікацій є ).
Олексій: Моє питання таке: чи відбувається цей бар'єр із самої природи поняття?
Майкл: Ні. Саріта дійшов висновку, що при правильному підході можна успішно приховати всю складність, отримати високу продуктивність та дати програмісту простий API. І якщо дотримуватися цього API, то можна досягти послідовної узгодженості. Вважаю, що це правильна модель. Пишете код без перегонів даних та отримуєте послідовну узгодженість. Звичайно, для того, щоб зменшити ймовірність перегонів, потрібні спеціальні інструменти, але це вже інше питання.
Володимир: Чи були у вашій кар'єрі випадки, коли проблема, яка здавалася вирішеною, раптом оберталася цілою катастрофою, чи з'ясовувалося, що ця проблема не вирішується? Наприклад, теоретично можна факторизувати будь-яке число чи визначити, чи є будь-яке число простим. Але на практиці це буває складно зробити, з існуючим залізом зараз складно факторизувати числа. Чи відбувалося щось подібне до вас?
Майкл: Відразу нічого подібного не згадується Бувало, коли мені здавалося, що в деякій сфері робити нічого, а потім там відбувалося щось нове і цікаве. Наприклад, я думав, що в галузі необмежених черг уже досягнуто зрілості. Після кількох покращень для черги MNS нічого особливого вже не відбувалося. А потім Моррісон (Adam Morrison) та Афек (Yehuda Afek) винайшли . Стало ясно, що можлива необмежена багатопотокова черга, у яких більшу частину часу на критичному шляху була лише інструкція fetch-and-increment. І це дозволяло досягти на порядок кращої продуктивності. Не те що ми не знали б, що fetch-and-increment дуже корисна річ. Ерік Фрейдентал (Eric Freudenthal) писав про це у своїй роботі про Ultracomputer з Аланом Готтлібом (Allan Gottlieb) наприкінці 1980-х, але там йшлося про обмежені черги. Моррісон та Афек змогли використати fetch-and-increment у необмеженій черзі.
Нові архітектури. Чи близька перемога транзакційної пам'яті?
Володимир: Чи стежите ви за новими архітектурними рішеннями, які могли б бути корисними для алгоритмів?
Майкл: Звичайно, є безліч речей, які мені хотілося б, щоб були реалізовані
Володимир: А які, наприклад?
Майкл: У першу чергу - кілька простих розширень для нашої транзакційної пам'яті апаратного рівня в процесорах Intel та IBM Особливо мені хотілося б, щоб не-транзакційні щойно відбулися load і store були відразу доступні всередині транзакцій. Вони відразу ж призводять до циклів у послідовності happens-before, тому з ними можуть бути складності. Але якщо підтримувати рівні абстракції, існує безліч дуже цікавих речей, які можна зробити поза транзакцією, поки вона відбувається. Я не знаю, наскільки важко було б це реалізувати, але це було б дуже корисно.
Інша корисна річ – завантаження кеша з віддаленої пам'яті. Думаю, рано чи пізно це буде зроблено. Ця технологія дозволить створювати системи із дезагрегованою пам'яттю. Можна буде тримати, скажімо, 100 терабайт енергонезалежної пам'яті в стійці, і операційна система сама динамічно вирішуватиме, які розділи пам'яті повинні відповідати фізичному адресному простору процесорів. Це було б вкрай корисно для хмарних обчислень, оскільки дозволило б надавати великі обсяги пам'яті тим завданням, які її потребують. Думаю, хтось це зробить.
Віталій: Щоб закінчити розмову про транзакційну пам'ять, у мене є ще одне питання з цієї теми Чи витіснить транзакційна пам'ять зрештою стандартні багатопотокові структури даних?
Майкл: Ні. Транзакції – це спекулятивний механізм. На рівні програмування це атомарні блокування, а всередині спекуляції. Таке прогнозування працює у тому випадку, якщо більшість припущень правильні. Тому транзакційна пам'ять добре працює тоді, коли потоки майже не взаємодіють один з одним, і потрібно просто переконатися, що взаємодій немає. Але якщо між тредами починається повідомлення, транзакцій мало користі. Поясню, йдеться про випадок, коли транзакції обернуті навколо всієї атомарної операції. Вони все одно можуть успішно використовуватися як складові частини для багатопоточних структури даних. Наприклад, якщо необхідний CAS із трьох слів, і потрібно виконати в режимі багатопоточності три невеликі речі серед дійсно багатопоточного алгоритму, який працює з двадцятьма тредами одночасно. Загалом, транзакції можуть бути корисними, але необхідності правильно проектувати багатопоточні структури даних вони не позбавлять.
Енергонезалежна пам'ять, Optane DIMM, надшвидкі пристрої.
Віталій: Останнє, про що я хотів би поговорити — це тема ваших поточних досліджень: енергонезалежна пам'ять Чого можна в цій галузі чекати у найближчому майбутньому? Можливо, вам відомі якісь вже існуючі ефективні реалізації?
Майкл: Я не експерт із заліза, я знаю тільки те, що читаю в новинах і що мені розповідають колеги Усі вже чули, що Intel продає , у яких десь у 3 рази більша затримка читання та у 10 разів більша затримка запису, ніж у динамічних RAM. Незабаром вони будуть доступні у версіях із дуже великим обсягом. Забавно думати про те, що можна буде мати ноутбук з кількома терабайтами RAM, що адресується в байтах. Цілком імовірно, що через 10 років ми вирішимо використовувати цю нову технологію, тому що ми використовуємо DRAM просто нарощувати обсяги. Але завдяки енергонезалежності у нас відкриваються нові можливості. Ми можемо докорінно змінити стек зберігання даних, щоб уникнути поділу між адресованої в байтах робочої пам'яттю і блочно-структурированной персистентної пам'яттю. Таким чином, нам не потрібно буде серіалізувати в блочно-структуровані файли все, що потрібно перенести з одного запуску програми в інший. З цього можна вивести безліч важливих принципів, що впливають на операційні системи, середовища виконання та розподілені сховища даних. У цій галузі дуже цікаво працювати. Особисто мені складно передбачити, у що це все виллється, але проблеми тут дуже цікаві. Можливо, тут відбудуться революційні зміни, і вони дуже природно випливають із роботи над багатопоточністю, оскільки відновлення після збою є «багатопоточним» процесом поруч із звичайною роботою системи.
Друга головна тема, над якою я зараз працюю — це управління надшвидкими пристроями та безпечний доступ до пристроїв із юзерспейсу із системним контролем над політикою. Останніми роками спостерігається тренд переміщати доступом до пристрою в юзерспейс. Це робиться через те, що поверх мережного інтерфейсу, якому потрібен новий пакет кожні 5 мікросекунд, не може функціонувати TCP-IP стек ядра, він просто не встигатиме. Тому виробники надають прямий доступ до пристроїв. Але це означає, що операційна система втрачає контроль над процесом, і вона не може забезпечити правильний доступ до пристрою для додатків, що змагаються. Наша дослідницька група вважає, що цього недоліку можна уникнути. USENIX ATC цього місяця буде наша стаття про це. Вона пов'язана з роботою над персистентністю, оскільки довговічна персистентна пам'ять, що адресується в байтах є, по суті, пристроєм з надшвидким I/O, до якого потрібно надати доступ в юзерспейсі. Ці дослідження уможливлюють нові підходи до мікроядрів, екзоядрів та інших традиційних спроб безпечно перенести функціональність з ядра ОС в юзерспейс.
Володимир: Пам'ять, що адресується в байтах, - це чудово, але є фізичне обмеження - швидкість світла А це означає, що неминуче буде затримка при взаємодії із пристроєм.
Майкл: Абсолютно вірно.
Володимир: Чи вистачить потужностей для того, щоб упоратися з новими навантаженнями?
Майкл: Це чудове питання, але мені на нього складно буде щось відповісти Вже давно існує ідея обробки в пам'яті, вона дуже цікава, але і дуже складна. Я в цій галузі не працював, але було б чудово, якби там було зроблено якісь відкриття. Боюся, мені більше додати нічого.
Володимир: Є ще одна проблема Нові, значно більші обсяги RAM неможливо буде розмістити в CPU. Тому через фізичні обмеження ця RAM має бути ізольованою.
Майкл: Тут все залежить від кількості дефектів при виробництві інтегральних схем Якби можна було створювати напівпровідникові пластини без дефектів, то з неї можна було б повністю зробити мікросхему. Але зараз ми не вміємо робити мікросхеми більше за поштові марки.
Володимир: Але мова все одно йде про величезні розміри, про сантиметри Це неминуче впливає на затримку.
Майкл: Так Зі швидкістю світла нічого не вдієш.
Володимир: На жаль.
Наступний великий тренд. Dual data structures. Hydra.
Віталій: Наскільки я розумію, ви дуже швидко вловлюєте нові тренди Ви були одним із перших, хто почав займатися транзакційною пам'яттю, і одним із перших у енергонезалежній пам'яті. Як ви вважаєте, який буде наступний важливий тренд? Чи, може, це секрет?
Майкл: Чесно кажу, що не знаю Сподіваюся, мені пощастить помітити, коли виникне щось нове. Мені не пощастило винайти поодинці якусь нову область, але кілька разів пощастило, і я зміг досить рано почати працювати в нових сферах, створених іншими. Сподіваюся, мені це вдаватиметься і в майбутньому.
Олексій: Останнє питання в цьому інтерв'ю буде про ваш виступ на Hydra та заняття у школі Якщо я правильно зрозумів, то доповідь на школі буде про алгоритми без блокування, а на конференції про подвійні структури даних. Чи не могли б ви сказати пару слів про ці доповіді?
Майкл: Почасти ми вже торкалися цих тем з вами в цьому інтерв'ю Йтиметься про роботу, яку я вів з моїм студентом Біллом Шерером. Він написав на основі її дисертацію, і в ній також брав участь Даг Лі, а зрештою вона стала частиною багатопоточних синхронних черг у бібліотеці Java. Припустимо, відбувається читання та запис у структуру даних без блокування, тобто кожна операція має обмежену кількість інструкцій на критичному шляху. Якщо спробувати вилучити дані з порожнього контейнера, або спробувати вилучити певні дані, яких у цьому контейнері немає, відразу повідомляється, що це зробити неможливо. Але така поведінка може бути неприпустимою, якщо ці дані дуже потрібні треду. Тоді перше, що спадає на думку — це створити цикл, який постійно запитуватиме, чи не з'явилися необхідні дані. Але тоді виникають перешкоди для решти. Крім того, за такого підходу можна чекати 10 хвилин, а потім прийде якийсь інший тред, і він випадково отримає необхідні дані першим. У подвійних структурах даних, як і раніше, немає блокувань, але вони дозволяють правильно організувати очікування тредів. Термін «подвійна» означає, що структура містить дані, або запити на дані, назвемо їх анти-дані. Тож якщо спробувати витягти щось із порожнього контейнера, то натомість у контейнер буде покладено запит. Тепер тред може чекати на запит і при цьому нікого іншого не турбувати. Крім того, структура даних призначає запитам пріоритети, тому при отриманні вона передає їх тому, кому слід. Виходить механізм без блокування, який має формальну специфікацію і хорошу продуктивність на практиці.
Олексій: Які ваші очікування від цієї структури даних? Чи дозволить вона покращити продуктивність у всіх типових випадках, чи вона краще підходить для певних ситуацій?
Майкл: Вона корисна у разі, якщо, по-перше, необхідний контейнер без блокування, і, по-друге, потрібно чекати у ситуації, коли з контейнера необхідно витягти дані, яких у ньому немає. Наскільки мені відомо, наша структура забезпечує оптимальну поведінку у разі, коли дотримуються цих двох умов. Тому у цих випадках я рекомендую її використовувати. Головна перевага структур даних без блокування в тому, що вони дозволяють уникнути проблем із продуктивністю. А очікування дуже важливе в багатьох алгоритмах, якщо відбувається передача даних з одного треду до іншого.
Віталій: Дозвольте уточнити: ви говоритимете про те саме і в школі, і на конференції?
Майкл: На школі в цілому про багатопотокові структури даних, з викладом основних принципів на початку заняття. Я маю на увазі, що аудиторія знає, що таке потоки, і знайома з блокуваннями. Орієнтуючись на ці базові знання, я розповідатиму про структури даних без блокувань. Я дам огляд найбільш важливих проблем у цій галузі, торкнуся теми на кшталт управління пам'яттю. Не думаю, що там буде щось складніше за чергу MS.
Олексій: Чи плануєте ви розповісти про подвійні структури даних наприкінці вашого заняття у школі?
Майкл: Я їх згадаю, але багато часу приділяти їм не буду Їм буде присвячена доповідь Hydra. Там буде розказано про проект, який у результаті увійшов до Java, а також про роботу з Джо Ізраєлевичем над створенням подвійного варіанта черги LCRQ, та про створення майже універсальної конструкції для подвійних структур даних.
Олексій: Тобто лекцію в школі можна порекомендувати для новачків, а лекцію про подвійні структури даних на Hydra — для людей, які вже мають якийсь досвід?
Майкл: Поправте мене, якщо я не правий, але аудиторія на Hydra буде досить різноплановою, у тому числі там буде багато експертів з Java, і взагалі людей, які спеціально багатопоточним програмуванням не займаються.
Віталій: Так це вірно.
Олексій: Принаймні, ми на це сподіваємось
Майкл: У цьому випадку переді мною буде та проблема, з обговорення якої ми почали це інтерв'ю: як зробити доповідь одночасно достатньою мірою насиченою технічними подробицями та доступною всім слухачам.
Віталій: Чи будете ви вести доповідь так, як ведете лекції? Тобто розмовляти з аудиторією та адаптуватися щодо ситуації?
Майкл: Боюся, так не вийде, тому що доповідь буде зі слайдами Слайди важливі, коли слухачі спочатку розмовляють різними мовами. Багатьом буде складно зрозуміти мене англійською, особливо якщо я говоритиму надто швидко. Я вибрав саме ці теми, бо попросив мене розповісти про структури даних без блокування на Школі SPTDC; а потім стала потрібна доповідь для конференції користувача-групи Java, і я хотів вибрати щось, що було б цікаво саме програмістам Java. Найпростіше було розповісти про ті речі в бібліотеці Java, до яких я так чи інакше приклав руку.
Олексій: Ми припускаємо, що аудиторія на Hydra вже щось знає про програмування без блокувань і, можливо, має якийсь досвід у цій галузі Але це тільки припущення, що ситуація стане більш ясною вже на самій конференції. Так чи інакше, дякую за те, що приділили нам час. Я впевнений, що інтерв'ю буде дуже цікавим нашим читачам. Велике спасибі!
Віталій: Дякую.
Майкл: Я буду радий зустрітися з вами у Санкт-Петербурзі
Олексій: Ми теж, у нас гарне місто Ви тут колись були?
Майкл: Ні, я взагалі в Росії жодного разу не був Але Санкт-Петербург завжди входив до списку місць, де ще не був, але де дуже хочу побувати, тому я дуже зрадів запрошенню.
Олексій: До речі, у нас буде програма екскурсій для доповідачів Дякую за інтерв'ю, і вдалого вам дня!
Продовжити спілкування з Майклом можна буде на конференції Hydra 2019, яка відбудеться 11-12 липня 2019 року у Санкт-Петербурзі. Він приїде з доповіддю . Квитки можна придбати .
Джерело: habr.com