Сегодня общался со знакомым - ровно такая же проблема случилась где-то в пятницу. Все индентично. Но, что самое интересное, у него крутился личный Gitlab (образ в Docker) за VPN. То есть напрямую в Интернет Gitlab не торчал. Есть подозрения, что зараза попала в то время, пока он был подключен к VPN. Постараюсь выяснить подробности.
UPD. Забыл добавить, сам Gitlab на Linux крутится, через VPN подключается только с Мака.
Я, по-моему, уже раз 5 тут привел пример со сборкой разными компиляторами и разными режимами, но адекватного ответа, как это реализовать не услышал — все сводится к каким-то костылям. Не вижу смысла переливать из пустого в порожнего. Хотите сидеть в прошлом веке — сидите на здоровье и пишите вручную makefile и проекты для VS.
В случае правильного использования CMake, я ничего не правлю и не копирую и не забиваю голову этой ерундой — проект конфигурируется, генерируется и собирается. Зачем все эти костыли, что вы предлагаете? CMake как раз был создан для того, чтобы не плодить эти костыли.
По-моему, вы никак не можете осознать, что ваш подход вносит ограничения на сборку (а если у меня исходники расшарены в директории «только для чтения»?) и работает только в определенных случаях, в то время когда свободный выбор директории сборки (в том числе, хоть в самой директории с исходниками) таких ограничений не накладывает.
Я ничего не демонизирую, это нормальная современная практика. А если мне нужно собирать как в release, так и в debug режимах? Уже две папки надо предусмотреть? А если еще в x86 и в x64? А еще люди под разные платформы собирают (например, под разные версии iOS/Android), им что делать с вашей папкой?
Наверно тем, что при использовании отдельной сборочной binary dir она не нужна, от слова совсем? В голове можно держать другие вещи, помимо того, надо ли сделать чистку исходников или нет.
Какой-то специфичный кейс. Да и можно просто настроить разные папки сборок для разных компиляторов.
Вы в Visual Studio работали, например? Там есть переключение между сборками Release/Debug, а также между x86/x64. И что, мне теперь 4 копии исходников держать, чтобы в разных режимах собирать? Это самый обычный use case.
Например отсутствие необходимости настройки сборки вне репозитория. Это сложнее, чем просто добавить соответствующий .gitignore, а пути сборки при этом нестандартные. Т.е. новички могут не понять куда собирается проект.
О какой сложности вы говорите, если в том же CMake это из коробки есть? Я никогда ничего в CMake-проектах не настраиваю, чтобы собрать в отдельной папке.
Как уже отметили, если язык и средства предоставляют такую возможность, то это как содержать квартиру в чистоте. Можно, конечно, разбрасывать мусор и либо его не замечать (а-ля .gitignore), либо периодически чистить (а-ля make clean). Но лучше, когда мусора нет совсем. Это удобно, например, когда приходят гости (надо отдать архив исходников кому-то или взять с собой). Еще одним плюсом чистоты является возможность одновременной (я имею ввиду быстрое переключение без необходимости пересобирать все) сборки несколькими компиляторами и в нескольких режимах, с разными параметрами сборки. Ну и чистить легко — просто удаляется директория сборки, и это гарантирует, что где-то среди исходников не затерялся какой-то объектник, который потом может быть подхвачен кривым makefile. А вот плюсов собирать прямо в дереве исходников — я лично не вижу.
Что CMake, что Autotools, давно поддерживают и продвигают эту концепцию сборки. Равно как и современные IDE, например Qt Creator. Действительно очень удобная штука, которая, например, позволяет одновременно иметь несколько сборок различного типа (release/debug) с легкостью переключения между ними.
Спасибо за статью, в общем и целом согласен. Единственное но: за сборку проекта в дереве исходников надо очень больно бить по рукам. Сегодня практически все современные системы поддерживают out-of-source сборку, вследствие чего необходимость .gitignore отпадает.
Подход с семафором, конечно, должен работать, так как это, по сути, аналог условной переменной. В статье же используется событие, так что в данной реализации одна секция не прокатит, нужно заменять событие чем-то.
Строго говоря, да, под XP у нас reentrant, а под все остальное нет.
Я бы так не сказал точно, но в большинстве случаев, это будет скорее верно. Нюанс в том, что стандарт POSIX не накладывает ограничения на это:
Results are undefined if the calling thread holds the read-write lock (whether a read or write lock) at the time the call is made.
То есть лучше на это не рассчитывать, так как Linux имеет полное право использовать рекурсивные блокировки.
Windows 7/8/10
Честно говоря, не понимаю, почему вы так выкидываете из обоймы XP, когда ее рыночная доля сопоставима с 8-й. Конечно, проще выкинуть и не заморачиваться, но ведь куда интереснее сделать реально кроссплатформенную вещь :) Без XP ваша статья как бы теряет смысл.
Тем не менее, эта задача решается с одной блокировкой.
Может быть, тогда вы представите это решение?
Это не должно влиять на ожидание писателем, он будет по-прежнему в очереди. При выполнении операции «отпуск» мы видим, что у нас есть ожидающий писатель, и можем разбудить его. Или же читателя в противном случае.
Вы совсем не слышите, что вам говорят. В момент перехвата читателем и в момент его отпуска нет никаких ожидающих писателей. Либо есть ожидающий писатель, но не исходный, а другой — тоже перехвативший управление.
Нужен счетчик, а не флаг в таком случае.
Либо вы что-то не понимаете в многопоточности, либо мои понятия о ней устарели. Счетчик вас не спасет, потому что читатель может перехватить управление несколько раз подряд, успешно обнулив счетчик.
Честно говоря, дискуссия теряет смысл, потому что вы продолжаете твердить свое, придумывая одну идею за другой. Предлагаю вам представить ваше решение проблемы, тогда будет предмет для конструктивного обсуждения.
Проблема в том, что при наличии одной секции, перед тем, как вставать на ожидание сигнала, вы вынуждены отпускать единственную глобальную блокировку, и вот тут и могут произойти неприятные вещи: могут встревать как потоки чтения, так и записи. Поэтому обычно то, о чем вы говорите, решается с использованием одной критической секции и условной переменной, которая позволяет сохранить атомарность при разблокировке секции и постановке на ожидание сигнала.
Более того, всегда при отпуске будить всех может не сработать по той причине, что если вы дадите сигнал до отпускания секции, то ситуация может повториться (писатель все еще держит секцию), а если после — то опять же, все возвращается к тому случаю, когда управление может перехватить читатель.
Почему, если у нас выставлен флаг waitingWriter? Второй писатель не должен получить доступ, раз уже есть один ожидающий — он должен сам свалиться в Wait, а тем временем будет разбужен первый писатель.
Потому что вы немного выдернули мою цитату из контекста и забыли про читателя. Если после отпускания секции и перед началом ожидания события сперва встрянет читатель, то он скинет этот флаг при разблокировке. После этого встревает другой писатель, а первый писатель так и остается ждать события со сброшенным флагом.
С критической секцией rwlock делается либо с двумя, либо с одной + условная переменная.
Если вы перед уходом в ожидание события разблокируете единственную секцию, то в этот момент читатель может разблокироваться, и тут же другой писатель может перехватить контроль. В итоге первый писатель может остаться ждать в тот момент, когда читателей и писателей реально нет (при разблокировке писателя отпускается только секция, сигнала нет).
Во-первых, реализация под Vista не является reentrant, что прямо следует из документации:
An SRW lock is the size of a pointer. The advantage is that it is fast to update the lock state. The disadvantage is that very little state information can be stored, so SRW locks cannot be acquired recursively.
В то время как критическая секция является reentrant, откуда вы получаете разное поведение под разные версии ОС.
Во-вторых, зачем городить огород из двух критических секций и события, когда можно обойтись одним событием и атомарными операциями? Это лишние накладные расходы. Обратите внимание на название примитива под Vista — это не просто так, что он занимает в памяти всего размер указателя. Для примера, как можно обойтись без критических секций, я делал в свое время это на C так (тоже под разные версии ОС). В свою очередь, есть уже готовая библиотека с выбором реализаций на любой вкус: RWLock (neosmart).
То есть представленное решение далеко не самое оптимальное, я бы не рекомендовал его использовать.
Ну вот, что называется, прощай Jolla! Видимо, история людей мало чему учит и многие считают, что уж их-то точно пронесет. Что OS/2 убила себя хорошей совместимостью с Windows, что webOS использовали как запускалку JS и HTML, что BlackBerry столкнулась с той же проблемой, ощутив наплыв Android-портов (зачастую очень посредственных). Скорее всего, то же самое ждет и Jolla — наклепают портов с Android и забьют на нативные приложения. А это, по сути, смерть для любой платформы. Ведь зачем разработчику писать качественные и нативные приложения, которые поддерживают все фишки ОС, если можно портануть и не париться, получая деньги, потратив минимум времени? А пользователи в свою очередь будут ждать нативные приложения, и получается замкнутый круг. Достаточно сейчас взглянуть на BlackBerry, чтобы понять, о чем я говорю: магазин наводнен Android-портами, качественных нативных приложений очень мало, и новых появляется мало. Правда, видимо, BlackBerry наконец-то осознала промах и сейчас пытается продвигать разработку нативных приложений, так что надежда еще есть. Да и деньг
Очень жаль, что Jolla выбрала такую стратегию построения экосистемы (пардон, экосистема-то не их), которая превратит ОС просто в еще одну хорошую (надеюсь) Android-пускалку.
Сегодня общался со знакомым - ровно такая же проблема случилась где-то в пятницу. Все индентично. Но, что самое интересное, у него крутился личный Gitlab (образ в Docker) за VPN. То есть напрямую в Интернет Gitlab не торчал. Есть подозрения, что зараза попала в то время, пока он был подключен к VPN. Постараюсь выяснить подробности.
UPD. Забыл добавить, сам Gitlab на Linux крутится, через VPN подключается только с Мака.
Наверно тем, что при использовании отдельной сборочной binary dir она не нужна, от слова совсем? В голове можно держать другие вещи, помимо того, надо ли сделать чистку исходников или нет.
Вы в Visual Studio работали, например? Там есть переключение между сборками Release/Debug, а также между x86/x64. И что, мне теперь 4 копии исходников держать, чтобы в разных режимах собирать? Это самый обычный use case.
О какой сложности вы говорите, если в том же CMake это из коробки есть? Я никогда ничего в CMake-проектах не настраиваю, чтобы собрать в отдельной папке.
Я бы так не сказал точно, но в большинстве случаев, это будет скорее верно. Нюанс в том, что стандарт POSIX не накладывает ограничения на это:
То есть лучше на это не рассчитывать, так как Linux имеет полное право использовать рекурсивные блокировки.
Честно говоря, не понимаю, почему вы так выкидываете из обоймы XP, когда ее рыночная доля сопоставима с 8-й. Конечно, проще выкинуть и не заморачиваться, но ведь куда интереснее сделать реально кроссплатформенную вещь :) Без XP ваша статья как бы теряет смысл.
Может быть, тогда вы представите это решение?
Вы совсем не слышите, что вам говорят. В момент перехвата читателем и в момент его отпуска нет никаких ожидающих писателей. Либо есть ожидающий писатель, но не исходный, а другой — тоже перехвативший управление.
Либо вы что-то не понимаете в многопоточности, либо мои понятия о ней устарели. Счетчик вас не спасет, потому что читатель может перехватить управление несколько раз подряд, успешно обнулив счетчик.
Честно говоря, дискуссия теряет смысл, потому что вы продолжаете твердить свое, придумывая одну идею за другой. Предлагаю вам представить ваше решение проблемы, тогда будет предмет для конструктивного обсуждения.
Проблема в том, что при наличии одной секции, перед тем, как вставать на ожидание сигнала, вы вынуждены отпускать единственную глобальную блокировку, и вот тут и могут произойти неприятные вещи: могут встревать как потоки чтения, так и записи. Поэтому обычно то, о чем вы говорите, решается с использованием одной критической секции и условной переменной, которая позволяет сохранить атомарность при разблокировке секции и постановке на ожидание сигнала.
Более того, всегда при отпуске будить всех может не сработать по той причине, что если вы дадите сигнал до отпускания секции, то ситуация может повториться (писатель все еще держит секцию), а если после — то опять же, все возвращается к тому случаю, когда управление может перехватить читатель.
Потому что вы немного выдернули мою цитату из контекста и забыли про читателя. Если после отпускания секции и перед началом ожидания события сперва встрянет читатель, то он скинет этот флаг при разблокировке. После этого встревает другой писатель, а первый писатель так и остается ждать события со сброшенным флагом.
С критической секцией rwlock делается либо с двумя, либо с одной + условная переменная.
Если вы перед уходом в ожидание события разблокируете единственную секцию, то в этот момент читатель может разблокироваться, и тут же другой писатель может перехватить контроль. В итоге первый писатель может остаться ждать в тот момент, когда читателей и писателей реально нет (при разблокировке писателя отпускается только секция, сигнала нет).
Во-первых, реализация под Vista не является reentrant, что прямо следует из документации:
В то время как критическая секция является reentrant, откуда вы получаете разное поведение под разные версии ОС.
Во-вторых, зачем городить огород из двух критических секций и события, когда можно обойтись одним событием и атомарными операциями? Это лишние накладные расходы. Обратите внимание на название примитива под Vista — это не просто так, что он занимает в памяти всего размер указателя. Для примера, как можно обойтись без критических секций, я делал в свое время это на C так (тоже под разные версии ОС). В свою очередь, есть уже готовая библиотека с выбором реализаций на любой вкус: RWLock (neosmart).
То есть представленное решение далеко не самое оптимальное, я бы не рекомендовал его использовать.
Очень жаль, что Jolla выбрала такую стратегию построения экосистемы (пардон, экосистема-то не их), которая превратит ОС просто в еще одну хорошую (надеюсь) Android-пускалку.