В таком случае семафор не поможет, так как блокирует поток, а он у нас (упс) один. С другой стороны он и не нужен, так как последовательные манипуляции с глобальной переменной выполнятся в одном потоке атомарно, не важно сколько промисов с ней взаимодействуют.
Покажу на примере: есть два промиса, один увеличивает счетчик, если он в нуле, другой уменьшает, если он в единице - в итоге ожидаем увидеть 0.
let sharedCounter = 0;
const checkAndChange = () => {
const isZero = sharedCounter === 0;
// сюда не проберется никакой другой поток
if (isZero) {
sharedCounter += 1;
} else {
sharedCounter -= 1;
}
}
const incrementIfZero = new Promise((resolve) => {
resolve(checkAndChange());
});
const decrementIfNonZero = new Promise((resolve) => {
resolve(checkAndChange());
});
Promise.all([incrementIfZero, decrementIfNonZero]).then(() => {
console.log(`Result: ${sharedCounter}`);
});
Как написал выше, код в функции checkAndChange выполнится атомарно, никто не может поменять переменную sharedCounter в процессе его выполнения, если программа выполняется в одном потоке.
Другая ситуация, если проверка и манипуляции с переменной происходят в теле промиса и затем в then-колбэке.
В этом случае как раз не увидим в результате нуля, потому что сначала выполнятся код в теле промиса, а уже затем then-обработчики. Но здесь в первую очередь вопросики к такой реализации, а не повод применять семафор.
Да, тоже кроме описанного в статье случая не нашел подобного в CSS. К счастью не потащили эту "фичу" дальше.
Ага, Sanitizer API можно использовать официально со вчерашнего дня, пока, правда только в Хроме: https://caniuse.com/mdn-api_sanitizer. Не знал, что он на основе DOMPurify, спасибо за открытие!
В таком случае мы, получается, идем вразрез с логикой браузера, если она реализует спецификации HTML касательно работы с тегами. Мы вправе только убрать потенциально опасные атрибуты, если говорить именно про санитайзеры. А если разговор про частное решение для конкретного приложения, то да, можем наворотить свою логику.
// Ждем пока освободится место для нашего потока, то есть счетчик станет больше 0
Atomics.wait(this.counter, 0, 0);
// Получаем значение счетчика
const n = Atomics.load(this.counter, 0);
// Еще раз проверям на то, что n > 0, так как другой поток мог вклиниться между wait и load
if (n > 0) {
// Пытаемся атомарно уменьшить счетчик, получив его предыдущее значение
const prev = Atomics.compareExchange(this.counter, 0, n, n - 1);
// Если prev === n, значит мы успешно уменьшили счетчик, все ок, можно выходить из цикла
if (prev === n) return;
// Eсли prev !== n, значит мы не изменили счетчик, надо пробовать снова - идем в начало цикла
}
Все так, реализуя и используя семафор, мы ожидаем, что другой поток может перехватить управление и войти в критическую секцию раньше первого потока. Единственное, в чем мы точно уверены в этом случае - одновременно в критической секции будет только один поток. Мьютекс же полностью заблокирует доступ к ресурсу, и снять его можно будет только из текущего потока (владельца ресурса).
Не совсем корректно сравнивать реализации композиции и наследования. Ведь композицию можно сделать иначе — без пересоздания объекта на каждый чих.
Только если логика приложения позволяет нам иметь одни и те же экземпляры функций для каждого юнита. В целом, конечно, это идеально, если мы можем их сохранить чистыми, да.
Спасибо за подробный разбор. По поводу совместного использования стамины и маны, безусловно в статье дико упрощенный пример далекий от реальности. Конечно, существует масса логики, усложняющей отношения между характеристиками, но он на то и пример. И, опять же, с анимацией, рассматривается простой пример внутренней бизнес логики приложения, как это будет отображаться и анимироваться — не ее зона ответственности.
Во-первых, нафиг такое усложнение с Object.assign, которое ломает автодополнение?
В примере ниже у каждого персонажа будет один и тот же экземпляр функции fight() или cast(). Вероятно, при усложнении логики этих функций потребуется внутреннее состояние, ссылка на оружие(свиток) и т.д. При конкатенации мы имеем уникальный экземпляр функции для каждого юнита.
Но про такую фигню статью не напишешь, да? Да и бгомеркий this, который используют только грязныё джависты. О, кстати, давайте соблюдать DRY.
Да, в комментариях ниже предложили более красивое решение с сохранением той же логики.
Можно вспомнить подобную же проблему с контекстной рекламой. Когда нибудь мы научимся рекламировать крем для обуви для только что купившего ботинки пользователя, а пока получай горы ботинок, причем максимально похожих на уже купленные.
Вполне вероятно задачу анализа поведения по движению курсора можно решить и аналитическими методами. Но это уже совсем другой уровень и исследований и реализации. В этом смысле рекурсивная нейросеть здесь — самый быстрый в реализации способ. Естественно с учетом использования готовой библиотеки.
Все так, сложно спорить, видится разве что два аргумента в защиту. С бОльшей вероятностью, вы окажетесь в числе 70% и останетесь довольны такой отзывчивостью. Ну и, конечно, инициатива магазина не должна быть такой навязчивой, чтобы открывать выпадающее меню в области фокуса внимания, а несколько небольших ссылок внизу экрана, например, уже не так страшны, даже если промазали с предсказанием.
В любом случае это уже совсем другая задача анализа тематики, а не механики движений.
С учетом базовой гигиены интерфейсов между между кнопкой и дропдауном должно быть определенное пространство. В идеале этой дистанции должно хватать чтобы разделить зоны, где пользователь собирается остановить курсор. В любом случае алгоритм предсказания должен это учитывать при настройке параметров того же фильтра частиц или скользящего среднего.
С тач-интерфейсами именно данные методы неприменимы, движения пальца вне контакта с экраном не отследишь. А для лэптопов/десктопов на первый взгляд выглядит не обременительно, по крайней мере тестовая реализация.
Да, согласен — ошибку первого рода надо держать в районе нуля и потом уже пытаться уменьшить пропуски. Не сработало — не так страшно, как лишнее событие.
А для расчета предполагаемой точки остановки курсора использовать нейросеть — перебор.
Скорее всего можно сделать это аналитически, да, нейросеть как самый быстрый в реализации способ — собрал статистику, обучил и вперед.
Вполне возможный сценарий развития событий, да.
Но опять же, статистика подскажет, что система работает неверно, если кнопку «подсветили», а пользователь не нажал. Маячок, что нужно до(пере)обучить.
Это уже проблема обучения. Если это большой сервис с постоянными пользователями, паттерны поведения каждого конкретного человека можно получить поизучав его действия в течение какого-то времени, а затем, дообучив алгоритм, уже показывать ему «предиктивный» вариант интерфейса. Нуу, в теории.
Это лишь эксперимент, но порядок величин примерно такой: полная сборка 40KB, из них 35KB — нейронная сеть с обвязкой для использования.
На практике, конечно, осуществимой идея выглядит с трудом. Но в плане ожидаемости для пользователя в каких-то узких конкретных случаях компании с огромной статистикой, вероятно, могли бы прийти к решению. Повлияют ли такие ухищрения на бизнес того же магазина — тоже вопрос, но другой.
Думаю, зависит от плотности движения. В месте, которое рассматривал, кажется, малая часть времени тратится на то, чтобы разойтись с встречным потоком.
Спасибо за внимание!
В таком случае семафор не поможет, так как блокирует поток, а он у нас (упс) один. С другой стороны он и не нужен, так как последовательные манипуляции с глобальной переменной выполнятся в одном потоке атомарно, не важно сколько промисов с ней взаимодействуют.
Покажу на примере: есть два промиса, один увеличивает счетчик, если он в нуле, другой уменьшает, если он в единице - в итоге ожидаем увидеть 0.
Как написал выше, код в функции checkAndChange выполнится атомарно, никто не может поменять переменную sharedCounter в процессе его выполнения, если программа выполняется в одном потоке.
Другая ситуация, если проверка и манипуляции с переменной происходят в теле промиса и затем в then-колбэке.
В этом случае как раз не увидим в результате нуля, потому что сначала выполнятся код в теле промиса, а уже затем then-обработчики. Но здесь в первую очередь вопросики к такой реализации, а не повод применять семафор.
У OWASP есть проект Top Ten, в нем на данный момент XSS на третьем месте, правда вместе с инъекциями.
Да, тоже кроме описанного в статье случая не нашел подобного в CSS. К счастью не потащили эту "фичу" дальше.
Ага, Sanitizer API можно использовать официально со вчерашнего дня, пока, правда только в Хроме: https://caniuse.com/mdn-api_sanitizer. Не знал, что он на основе DOMPurify, спасибо за открытие!
В таком случае мы, получается, идем вразрез с логикой браузера, если она реализует спецификации HTML касательно работы с тегами. Мы вправе только убрать потенциально опасные атрибуты, если говорить именно про санитайзеры. А если разговор про частное решение для конкретного приложения, то да, можем наворотить свою логику.
Должно быть верно, здесь логика следущая:
Все так, реализуя и используя семафор, мы ожидаем, что другой поток может перехватить управление и войти в критическую секцию раньше первого потока. Единственное, в чем мы точно уверены в этом случае - одновременно в критической секции будет только один поток. Мьютекс же полностью заблокирует доступ к ресурсу, и снять его можно будет только из текущего потока (владельца ресурса).
Только если логика приложения позволяет нам иметь одни и те же экземпляры функций для каждого юнита. В целом, конечно, это идеально, если мы можем их сохранить чистыми, да.
В примере ниже у каждого персонажа будет один и тот же экземпляр функции fight() или cast(). Вероятно, при усложнении логики этих функций потребуется внутреннее состояние, ссылка на оружие(свиток) и т.д. При конкатенации мы имеем уникальный экземпляр функции для каждого юнита.
Да, в комментариях ниже предложили более красивое решение с сохранением той же логики.
Вполне вероятно задачу анализа поведения по движению курсора можно решить и аналитическими методами. Но это уже совсем другой уровень и исследований и реализации. В этом смысле рекурсивная нейросеть здесь — самый быстрый в реализации способ. Естественно с учетом использования готовой библиотеки.
В любом случае это уже совсем другая задача анализа тематики, а не механики движений.
Скорее всего можно сделать это аналитически, да, нейросеть как самый быстрый в реализации способ — собрал статистику, обучил и вперед.
Страшно же, все на тебя смотрят, и телефон смотрит, и лэптоп.
Но опять же, статистика подскажет, что система работает неверно, если кнопку «подсветили», а пользователь не нажал. Маячок, что нужно до(пере)обучить.
На практике, конечно, осуществимой идея выглядит с трудом. Но в плане ожидаемости для пользователя в каких-то узких конкретных случаях компании с огромной статистикой, вероятно, могли бы прийти к решению. Повлияют ли такие ухищрения на бизнес того же магазина — тоже вопрос, но другой.