Когда мне было 10 лет, компьютеров в моём городке ни у кого не было. Когда мне стало 13 лет, у меня появился собранный родителями клон ZX Spectrum. Поскольку очень мало у кого из знакомых тоже были спектрумы, то основная проблема была в том, где достать игры и где достать информацию. Вместе с компьютером шли две кассеты с играми и руководство по Basic. Попробовав писать игры на Basic сам я понял, что они работают медленно, и решил поглядеть, а как же сделаны крутые коммерческие игры. Но оказалось, что они написаны в машинных кодах, так что посмотреть их логику не так-то и просто. В самом конце Basic-руководства было совсем чуть-чуть про машинные коды и ассемблер. Беда была в том, что собственно ассемблера у меня не было, и у друзей его не было, он же не игра. C Basic такой проблемы не стояло, он был зашит в ПЗУ вместе с редактором. Я пытался написать редактор+ассемблер на Basic, сначала максимально тупо: нужно было ввести текст команды и машинные коды (их получал вручную). Далеко этот прототип не продвинулся: я сговорился со знакомым дядькой поехать в Москву на радиорынок, и там купил кассету с коммерческими ассемблерами. Сначала был gens, потом перешёл на zeus.
Нехорошо огульно обвинять собеседника. Вы бы хоть в мой профиль глянули, увидели бы, что в двух моих статьях есть листинги на ассемблере (для Z80, но x86 я тоже знаю хорошо).
Копирует двухбайтовое значение из регистра BX в регистр AX, и оно пишется с запятой: mov ax, bx. И что за скобкосмайлы, такое употребляли лет 20 назад, пора бы уже перестать.
Ассемблер реально несложно парсить, там не нужно всё это LL/LR, рекурсивные спуски и прочее, тупая стейт-машина.
Я посмотрел, и там нифига не только транспилятор в JS, там ещё интерпретатор с рантаймом и системой типов, я хз, насколько оно рабочее, но нейронка нагенерила кучу кода. Я понимаю, что таких примеров немало на гитхабе, нейронкам есть где научиться, но пользоваться этим нет смысла, потому что функциональность таких интерпретируемых языков не сильнее, чем у существующих. Вот что бывает, когда попросишь нейронку сгенерить что-то, и она создаст систему, которую автор ни в каком случае не смог бы написать сам. И в комментариях в коде забавно перемежаются русский и английский языки.
Тут уже упомянули про нескучные обои, так вот: у этого языка предполагаются vlad-пакеты, для которых используется менеджер пакетов vladpm, сразу вспомнил "антивирус Попова".
Примеры читаются забавно, "let" нейронка перевела в некоторых местах как "пусть", а в других как "позволить", из-за чего код читается как царский указ: позволить это, позволить то, позволить сё, во какой я милостивый!
Вы так настойчиво продвигаете тезис, что приватное поле инициализируется через reflection, а конструктор - через new, но я вот сильно не уверен в new. Возможны два варианта: или reflection-вызов конструктора, или runtime-кодогенерация, в которой будет new. Я думаю, что используется reflection (я бы так сделал), и это несложно проверить: поставить точку останова в конструкторе и посмотреть стектрейс, но мне безумно лень. Упоминание производительности сразу было смешным: какая блин производительность инжекта, у вас же не миллиарды бинов инжектятся. А имея в виду то, что я в начале сказал, разница в производительности будет даже в пользу reflection.
Но общее моё отношение к теме статьи - а не пофиг ли, как оно инжектится? Много сильных слов: легаси, зомби, невалидное состояние, ну-ну, а это всё точно является проблемой?
Ссылку не дали, и такое не гуглится, я попробовал.
Но что если вам нужна именно полная картина — история 287 пар за 20 лет, включая экзотические связки вроде ILS/UYU или KWD/MYR?
Нафига? Такое торгуется через доллар как валюту-посредник.
Отлично, понимаю! Откорректируем статью:
Вычитайте уже нормально ваше LLM-поделие и уберите ошмётки диалогов с LLM-кой
Быстрая арифметика:
При линейной загрузке: 574 запроса / 8 запр./мин = 72 минуты (и это без учёта ошибок и пауз)
Казалось бы, задача на грани выполнимости. Но именно здесь начинается интересная часть — архитектурное решение.
Спойлер: Наш финальный скрипт загрузил все 287 пар за ~4.5 часа
72 минуты - это чуть больше часа, а вы сделали за 4.5 часа, это да, на грани выполнимости. Спросите LLM-ку, как сделать так, чтобы параллельно выполнялась сортировка/дедупликация загруженных данных и загрузка новых данных, "архитектурное решение" у них, понимаешь.
Ad hominem - прекрасная дубина, которой так приятно огреть автора-лентяя. С какой стати я буду подробно объяснять технические косяки человеку, который вряд ли хочет научиться, ведь он заставил работать ллм-ку только ради внимания и славы? А если я его тупо обзову, то он обидится и уйдёт, этого-то мне и надо.
Внимательно прочитал статью. Оно отдаёт нейросетью, но оригинальным образом: тут для текстовой массы используется не вода, а куча листингов. Пофиг, к делу.
Проблема 2: N+1 SELECT. Корень проблемы: ORM-механика: По умолчанию @ManyToOne и @OneToOne загружаются LAZY.
Проблема 4: EAGER загрузка. Почему это неочевидно: По умолчанию в JPA @ManyToOne и @OneToOne имеют стратегию загрузки EAGER
Вы уж определитесь.
В целом систематизация странная, каждый пункт мыслит очень узко. Например, пункт 3 говорит: медленная вставка - так это у вас батчинг не настроен. Настроили, всё равно медленная? Тогда пункт 1, id-поля неправильно генерятся. Или вот: пункт 4 такой: у вас N+1, потому что EAGER, поменяйте на LAZY. Поменяли, и всё равно N+1 ? А, так вы обращались к many-to-one полю в цикле, это вам в пункт 2, пишите запрос.
В проблеме 5 вы решили оптимизировать загрузку blob-колонок слишком радикально, аж в Mini-checklist для code review вынесли "[ ] Все @Lob поля помечены как @Basic(fetch = FetchType.LAZY)".Не надо так бездумно, вполне может оказаться, что Blob-поле нужно всегда.
В проблеме 7 в альтернативном подходе вы предлагаете объекты в цикле загружать. Если это Entity, то оно останется в кеше первого уровня, и всё равно память займёт.
Конкуренция "была" и снижение цен "было" - это тут ключевое
Я не согласен, я думаю, что конкуренция была и есть сейчас, но тогда была ценовая война, после этого таких периодов больше не было, вот и вся разница. Вы зачем-то объединяете эти вещи, не знаю зачем.
Теперь мы видим, что такой индустрии больше нет. Вернее она есть, но производство там рассчитано на применение комплектующих, производимыми несколькими крупными игроками рынка, диктующими цены.
Индустрия, конечно же, есть. Комплектующие и тогда, и сейчас, производились некоторыми крупными игроками рынка, тогда это были, если взять процессоры, Zilog, Intel, Motorola, MOS, TI.
Когда вы говорите про "производителей-игроков, диктующих цены", вы можете проиллюстрировать, в чём эта диктовка заключается? Потому что я этого не вижу, считаю ценообразование на чипы разумным с точки зрения производителей. Вообще я думаю, что это выражение вы употребили как часть своей антикапиталистической риторики, но вдруг. Ссылок на отдельные статьи-мнения не надо, был бы любопытен большой механизм.
за счет того что имела в собственности завод, выпускавший 6502 и 6510 и предугадав снижение цен на чипы памяти, получив в перспективе колоссальное снижение себестоимости
Ну дык, вот оно, про что я говорил - дядька рискнул, купив MOS и рисковал, снижая цены, и выиграл. А TI проиграли.
Только где это всё, чего это оно не развилось дальше?
Не совсем понял вопрос, что не развилось: система команд 6502, архитектура Commodore 64, бизнес-успешность фирмы Commodore?
Занятно, что вы взяли мой рассказ про рынок микрокомпьютеров в Европе-США в начале 80-x, увидели фразу про "снижение", и спрашиваете, почему это не работало в России в 2024 году. Я расскажу. В мире микрокопьютеров конкуренция была на многих уровнях: процессоры (6502, Z80), память, заводы электроники. Также там хорошо работает эффект массовости производства. Это позволило снижать издержки, из-за чего конкуренция происходила не только в соревновании характеристик компьютеров, но и в снижениях цен (и Спектрум, и BBC Micro, и Commodore резали цены только в путь). Не стоит забывать, что у них был доступ к заёмному капиталу. Перенесёмся в Россию. Военные действия, инфляция, ожидания экономических проблем приводят людей к мысли, что если не купить квартиру, то деньги пропадут, поэтому все покупают. Причём покупали и не на свои, пока были льготные ипотеки. К концу 2024 льготные ипотеки закончились, процентная ставка конская, спрос упал. Но застройщики считают (объективно), что надёжного вложения денег, кроме недвижимости, у людей нет всё равно, плюс верят, что народ ждёт снижения ставки, ибо ставку снизят, поэтому народ ждёт, и застройщикам можно подождать, так что придержали цены, и в 2025 с продажами было всё прекрасно. Снижение цен - не единственный способ конкуренции. Но если бы конкуренции не было, то цены были бы ещё выше, качество и разнообразие жилья гораздо ниже, и количество строящегося жилья было бы сильно ниже. Есть некоторая разница с требуемым размером капитала для входа на рынок строительства по сравнению с рынком микрокомпьютеров, и нюансы России в 2024 году.
В вашем вопросе "превосходство" звучит как что-то плохое, но вообще люди разные, да. Кто-то умнее, кто-то быстрее, кто-то выше ростом, кто-то крупнее. Некоторые из этих качеств можно тренировать. В предпринимательстве есть спортивный азарт, и нервы нужно иметь крепкие, если сильно рискуешь, это не всем комфортно.
Про "не считаться с интересами работников" я ничего не говорил, это вы мне набрасываете. Могу рассказать про то, как считались с интересами работников в СССР
Наверное это умение, а возможно и некий врожденный ген успешности, позволяет Илону Маску получать его прибыль и увеличивать капитал
Именно. Вы поёрничали, но само утверждение является истинным.
А вот вам реальная ситуация - есть один завод на Тайване, который производит тупо все чипы в мире. Проблемы у завода - лихорадит всю отрасль. Помните такое? Где конкуренция?
Он производит не все чипы в мире, конкуренция имеется. Степень лихорадки отрасли сильно преувеличена, с отраслью всё отлично. Если ваша идея в том, чтобы закопать меня в подробности и забыть тезис, то не выйдет: без конкуренции и предпринимательства сейчас были бы не нанометры, а микрометры, с гигантским процентом брака.
Про жильё - нифига не понял, каким образом ваш вопрос относится к моему объяснению.
Про как заработать 700 млрд. - элементарно. Нужно было год назад взять гигантский кредит, купить очень много микросхем памяти, сегодня продать. Ни одного наёмного работника, чистая прибыль. Но для этого нужно было риснуть, предположив, что рынок вырастет. Уже поздно.
Это скорее исключение, чем правило. Про Ultimate известно, что у них было что-то типа рабочей станиции Unix, большинство же Spectrum-игр делалось на Spectrum-ах или Amstrad-ах.
Суть предпринимательства не в эксплуатации, в СССР эксплуатация существовала не в меньшей степени. Суть предпринимательства в возможности увидеть спрос, попробовать его удовлетворить каким-то способом, вложить в реализацию способа средства, получить прибыль в случае, если видение оказалось верным, или потерять вложенные средства. Предпринимательство - это риск и умение делать суждения о рынке. У того же Синклера некоторые суждения (проц Z80, использование ULA) были удачными и ZX80, ZX81, ZX Spectrum взлетел, а потом QL жёстко облажался. У Acorn, которые делали BBC Micro и его друзей, было всё норм с технической частью, но они просчитались в продажном плане. Рискнули капиталом и проиграли. Но они теряли только капитал, потребители и рынок получали конкуренцию (в том числе техническую), разнообразие и снижение цен. А СССР с его плановой экономикой и бюрократией ждал, чего бы скопировать.
Второй уничтожил данные, которые рассчитал, исходя из старого значения ячейки памяти. Он зачитает обновлённые данные, заново пересчитает, скорее всего получит другое значение по сравнению с первой попыткой, и сохранит. Итого в памяти окажется результат выполнения двух действий, а не только первого.
Автор вынес за скобки обновление структурированных данных, он свёл задачу к обновлению чего-то одного. В примере с OrderService он выкрутился тем, что OrderState - иммутабельный , метод apply() создаёт изменённую копию, и нужно только переставить атомарную глобальную ссылку на созданную копию.
Насчёт того, зачем нужен First Win. Отличие варианта 1 от варианта 2 в том, что вариант 1 - оптимистический: сделал работу, веря, что результат удастся сохранить, потом пытаемся сохранить, а вариант 2 - пессимистический, не верим, что никто не обновит за то время, пока работаем, поэтому блокируемся. В некоторых случаях оптимистичный вариант лучше.
В качестве одного из способов, как сделать single writer (я бы назвал exclusive writer), предложена блокировка/mutex. Кстати, самый распространённый способ, как блокировку можно реализовать - это использовать First Win для ячейки памяти, пометив её идентификатором потока-владельца. И хотя это внутренние детали реализации примитива синхронизации, получается так что способ 2 достигается применением способа 1. С очередями аналогичная история.
Да, зацепился за ассемблер.
Когда мне было 10 лет, компьютеров в моём городке ни у кого не было. Когда мне стало 13 лет, у меня появился собранный родителями клон ZX Spectrum. Поскольку очень мало у кого из знакомых тоже были спектрумы, то основная проблема была в том, где достать игры и где достать информацию. Вместе с компьютером шли две кассеты с играми и руководство по Basic. Попробовав писать игры на Basic сам я понял, что они работают медленно, и решил поглядеть, а как же сделаны крутые коммерческие игры. Но оказалось, что они написаны в машинных кодах, так что посмотреть их логику не так-то и просто. В самом конце Basic-руководства было совсем чуть-чуть про машинные коды и ассемблер. Беда была в том, что собственно ассемблера у меня не было, и у друзей его не было, он же не игра. C Basic такой проблемы не стояло, он был зашит в ПЗУ вместе с редактором. Я пытался написать редактор+ассемблер на Basic, сначала максимально тупо: нужно было ввести текст команды и машинные коды (их получал вручную). Далеко этот прототип не продвинулся: я сговорился со знакомым дядькой поехать в Москву на радиорынок, и там купил кассету с коммерческими ассемблерами. Сначала был gens, потом перешёл на zeus.
Нехорошо огульно обвинять собеседника. Вы бы хоть в мой профиль глянули, увидели бы, что в двух моих статьях есть листинги на ассемблере (для Z80, но x86 я тоже знаю хорошо).
Копирует двухбайтовое значение из регистра BX в регистр AX, и оно пишется с запятой: mov ax, bx. И что за скобкосмайлы, такое употребляли лет 20 назад, пора бы уже перестать.
Ассемблер реально несложно парсить, там не нужно всё это LL/LR, рекурсивные спуски и прочее, тупая стейт-машина.
Я посмотрел, и там нифига не только транспилятор в JS, там ещё интерпретатор с рантаймом и системой типов, я хз, насколько оно рабочее, но нейронка нагенерила кучу кода. Я понимаю, что таких примеров немало на гитхабе, нейронкам есть где научиться, но пользоваться этим нет смысла, потому что функциональность таких интерпретируемых языков не сильнее, чем у существующих. Вот что бывает, когда попросишь нейронку сгенерить что-то, и она создаст систему, которую автор ни в каком случае не смог бы написать сам. И в комментариях в коде забавно перемежаются русский и английский языки.
Тут уже упомянули про нескучные обои, так вот: у этого языка предполагаются vlad-пакеты, для которых используется менеджер пакетов vladpm, сразу вспомнил "антивирус Попова".
Примеры читаются забавно, "let" нейронка перевела в некоторых местах как "пусть", а в других как "позволить", из-за чего код читается как царский указ: позволить это, позволить то, позволить сё, во какой я милостивый!
Синтаксис у ассемблера сильно проще, чем у JavaScript, а уж кодогенерация и подавно, попытка поёрничать не удалась.
Столько слов - потому что LLM-ка столько нагенерила. Проблема высосана из пальца.
Вы так настойчиво продвигаете тезис, что приватное поле инициализируется через reflection, а конструктор - через new, но я вот сильно не уверен в new. Возможны два варианта: или reflection-вызов конструктора, или runtime-кодогенерация, в которой будет new. Я думаю, что используется reflection (я бы так сделал), и это несложно проверить: поставить точку останова в конструкторе и посмотреть стектрейс, но мне безумно лень. Упоминание производительности сразу было смешным: какая блин производительность инжекта, у вас же не миллиарды бинов инжектятся. А имея в виду то, что я в начале сказал, разница в производительности будет даже в пользу reflection.
Но общее моё отношение к теме статьи - а не пофиг ли, как оно инжектится? Много сильных слов: легаси, зомби, невалидное состояние, ну-ну, а это всё точно является проблемой?
Ссылку не дали, и такое не гуглится, я попробовал.
Нафига? Такое торгуется через доллар как валюту-посредник.
Вычитайте уже нормально ваше LLM-поделие и уберите ошмётки диалогов с LLM-кой
72 минуты - это чуть больше часа, а вы сделали за 4.5 часа, это да, на грани выполнимости. Спросите LLM-ку, как сделать так, чтобы параллельно выполнялась сортировка/дедупликация загруженных данных и загрузка новых данных, "архитектурное решение" у них, понимаешь.
Ad hominem - прекрасная дубина, которой так приятно огреть автора-лентяя. С какой стати я буду подробно объяснять технические косяки человеку, который вряд ли хочет научиться, ведь он заставил работать ллм-ку только ради внимания и славы? А если я его тупо обзову, то он обидится и уйдёт, этого-то мне и надо.
Внимательно прочитал статью. Оно отдаёт нейросетью, но оригинальным образом: тут для текстовой массы используется не вода, а куча листингов. Пофиг, к делу.
Вы уж определитесь.
В целом систематизация странная, каждый пункт мыслит очень узко. Например, пункт 3 говорит: медленная вставка - так это у вас батчинг не настроен. Настроили, всё равно медленная? Тогда пункт 1, id-поля неправильно генерятся. Или вот: пункт 4 такой: у вас N+1, потому что EAGER, поменяйте на LAZY. Поменяли, и всё равно N+1 ? А, так вы обращались к many-to-one полю в цикле, это вам в пункт 2, пишите запрос.
В проблеме 5 вы решили оптимизировать загрузку blob-колонок слишком радикально, аж в Mini-checklist для code review вынесли "[ ] Все
@Lobполя помечены как@Basic(fetch = FetchType.LAZY)".Не надо так бездумно, вполне может оказаться, что Blob-поле нужно всегда.В проблеме 7 в альтернативном подходе вы предлагаете объекты в цикле загружать. Если это Entity, то оно останется в кеше первого уровня, и всё равно память займёт.
Я не согласен, я думаю, что конкуренция была и есть сейчас, но тогда была ценовая война, после этого таких периодов больше не было, вот и вся разница. Вы зачем-то объединяете эти вещи, не знаю зачем.
Индустрия, конечно же, есть. Комплектующие и тогда, и сейчас, производились некоторыми крупными игроками рынка, тогда это были, если взять процессоры, Zilog, Intel, Motorola, MOS, TI.
Когда вы говорите про "производителей-игроков, диктующих цены", вы можете проиллюстрировать, в чём эта диктовка заключается? Потому что я этого не вижу, считаю ценообразование на чипы разумным с точки зрения производителей. Вообще я думаю, что это выражение вы употребили как часть своей антикапиталистической риторики, но вдруг. Ссылок на отдельные статьи-мнения не надо, был бы любопытен большой механизм.
Ну дык, вот оно, про что я говорил - дядька рискнул, купив MOS и рисковал, снижая цены, и выиграл. А TI проиграли.
Не совсем понял вопрос, что не развилось: система команд 6502, архитектура Commodore 64, бизнес-успешность фирмы Commodore?
Занятно, что вы взяли мой рассказ про рынок микрокомпьютеров в Европе-США в начале 80-x, увидели фразу про "снижение", и спрашиваете, почему это не работало в России в 2024 году. Я расскажу. В мире микрокопьютеров конкуренция была на многих уровнях: процессоры (6502, Z80), память, заводы электроники. Также там хорошо работает эффект массовости производства. Это позволило снижать издержки, из-за чего конкуренция происходила не только в соревновании характеристик компьютеров, но и в снижениях цен (и Спектрум, и BBC Micro, и Commodore резали цены только в путь). Не стоит забывать, что у них был доступ к заёмному капиталу. Перенесёмся в Россию. Военные действия, инфляция, ожидания экономических проблем приводят людей к мысли, что если не купить квартиру, то деньги пропадут, поэтому все покупают. Причём покупали и не на свои, пока были льготные ипотеки. К концу 2024 льготные ипотеки закончились, процентная ставка конская, спрос упал. Но застройщики считают (объективно), что надёжного вложения денег, кроме недвижимости, у людей нет всё равно, плюс верят, что народ ждёт снижения ставки, ибо ставку снизят, поэтому народ ждёт, и застройщикам можно подождать, так что придержали цены, и в 2025 с продажами было всё прекрасно. Снижение цен - не единственный способ конкуренции. Но если бы конкуренции не было, то цены были бы ещё выше, качество и разнообразие жилья гораздо ниже, и количество строящегося жилья было бы сильно ниже. Есть некоторая разница с требуемым размером капитала для входа на рынок строительства по сравнению с рынком микрокомпьютеров, и нюансы России в 2024 году.
В вашем вопросе "превосходство" звучит как что-то плохое, но вообще люди разные, да. Кто-то умнее, кто-то быстрее, кто-то выше ростом, кто-то крупнее. Некоторые из этих качеств можно тренировать. В предпринимательстве есть спортивный азарт, и нервы нужно иметь крепкие, если сильно рискуешь, это не всем комфортно.
Про "не считаться с интересами работников" я ничего не говорил, это вы мне набрасываете. Могу рассказать про то, как считались с интересами работников в СССР
Именно. Вы поёрничали, но само утверждение является истинным.
Он производит не все чипы в мире, конкуренция имеется. Степень лихорадки отрасли сильно преувеличена, с отраслью всё отлично. Если ваша идея в том, чтобы закопать меня в подробности и забыть тезис, то не выйдет: без конкуренции и предпринимательства сейчас были бы не нанометры, а микрометры, с гигантским процентом брака.
Эксплуататором в СССР являлось государство.
Про жильё - нифига не понял, каким образом ваш вопрос относится к моему объяснению.
Про как заработать 700 млрд. - элементарно. Нужно было год назад взять гигантский кредит, купить очень много микросхем памяти, сегодня продать. Ни одного наёмного работника, чистая прибыль. Но для этого нужно было риснуть, предположив, что рынок вырастет. Уже поздно.
Это скорее исключение, чем правило. Про Ultimate известно, что у них было что-то типа рабочей станиции Unix, большинство же Spectrum-игр делалось на Spectrum-ах или Amstrad-ах.
Суть предпринимательства не в эксплуатации, в СССР эксплуатация существовала не в меньшей степени. Суть предпринимательства в возможности увидеть спрос, попробовать его удовлетворить каким-то способом, вложить в реализацию способа средства, получить прибыль в случае, если видение оказалось верным, или потерять вложенные средства. Предпринимательство - это риск и умение делать суждения о рынке. У того же Синклера некоторые суждения (проц Z80, использование ULA) были удачными и ZX80, ZX81, ZX Spectrum взлетел, а потом QL жёстко облажался. У Acorn, которые делали BBC Micro и его друзей, было всё норм с технической частью, но они просчитались в продажном плане. Рискнули капиталом и проиграли. Но они теряли только капитал, потребители и рынок получали конкуренцию (в том числе техническую), разнообразие и снижение цен. А СССР с его плановой экономикой и бюрократией ждал, чего бы скопировать.
Статья грамматически безграмотная и по смыслу ни о чём
Второй уничтожил данные, которые рассчитал, исходя из старого значения ячейки памяти. Он зачитает обновлённые данные, заново пересчитает, скорее всего получит другое значение по сравнению с первой попыткой, и сохранит. Итого в памяти окажется результат выполнения двух действий, а не только первого.
Автор вынес за скобки обновление структурированных данных, он свёл задачу к обновлению чего-то одного. В примере с OrderService он выкрутился тем, что OrderState - иммутабельный , метод apply() создаёт изменённую копию, и нужно только переставить атомарную глобальную ссылку на созданную копию.
Насчёт того, зачем нужен First Win. Отличие варианта 1 от варианта 2 в том, что вариант 1 - оптимистический: сделал работу, веря, что результат удастся сохранить, потом пытаемся сохранить, а вариант 2 - пессимистический, не верим, что никто не обновит за то время, пока работаем, поэтому блокируемся. В некоторых случаях оптимистичный вариант лучше.
В качестве одного из способов, как сделать single writer (я бы назвал exclusive writer), предложена блокировка/mutex. Кстати, самый распространённый способ, как блокировку можно реализовать - это использовать First Win для ячейки памяти, пометив её идентификатором потока-владельца. И хотя это внутренние детали реализации примитива синхронизации, получается так что способ 2 достигается применением способа 1. С очередями аналогичная история.