Ребята, есть уже готовый сайт для онлайн-подсчётов результатов выборов. Там же есть веб-интерфейс.
Возможно, вам имеет смысл с ними договориться объединить (с дублированием, например) ваши системы.
А почему, интересно, системная оппозиция (особенно КПРФ) не выложит в открытый доступ все свои протоколы, а кричит о подлогах, постоянно путаясь в цифрах? Почему они не выложат свои протоколы, чтобы стало видно, кто, где, и на каком этапе сфальсифицировал? Не значит ли это, что системная оппозиция имеет какие-то свои договорённости, и им выгодна не правда, а истерия?
Не надо нам рассказывать о чудесах и волшебстве!
Мы не в детском саду собрались.
Есть «правила игры».
Есть протоколы УИК, которые подписываются ВСЕМИ участниками комиссии и копии которых есть у всех участников УИК. Эти протоколы передаются наверх и суммируются.
Всё что нужно сделать гражданам — это просуммировать данные с копий протоколов УИК самостоятельно.
Всего таких протоколов будет порядка 100 тысяч.
Просуммировав, можно будет понять, на каком этапе произошла фальсификация и кто несёт за неё ответственность. Можно будет выяснить реальные цифры проголосовавших. В общем, можно будет выдавать данные параллельно (а может даже и раньше) с тем, как их посчитает центризбирком.
И ничего тут волшебного нет. Надо просто оторвать задницу от стула и принять участие в открытом, гражданском расчёте голосов.
А не визжать о «волшебнике Чурове» и его отставке.
Потому что если человек ответственен за фальсификации, то его надо судить по закону РФ. А если он перед законом чист, то оставить на своём месте. В любом случае, надо помнить, что в демократическом обществе существуют не только законы, но и презумпция невиновности.
Если речь идёт о передаче колбэков, то, да, они есть. И, кстати, не требуют никакого пост-процессинга исходников (Кьют ещё от него не отказался?)
Вот ссылка на описание. Посмотрите, пожалуйста, это ли Вы имели в виду, или нет.
Суть метода — в другой модели взаимодействия потоков (чётко оговорены ограничения, которые я накладываю на код С++). Я утверждаю, что применение данной модели позволяет создавать более стабильные и масштабируемые приложения без потери эффективности (практически или полностью) в сравнении с обычными объектами синхронизации. Как заметили здесь в комментариях, данный подход становится всё более актуальным с переходом на многоядерные процессоры.
Здесь мы говорим конкретно о коде на С++, а не о процессах. Поэтому я также уточняю конкретные требования к декомпозиции задачи на классы, а также уточняю обмена абстрактными сообщениями до передачи колбэков с копированием параметров (простым или разрушающим).
В комментариях мне написали, что я не единственный, кто изобретал этот велосипед. Параллельно со мной этим занимались как крупные компании вроде Интел, так и другие команды исследователей. Всего есть как минимум несколько библиотек, которые решают сходные задачи, но со своими особенностями.
Не могу не согласиться с приведённой фразой.
Однако, не могу согласиться с ней применительно к U++. Вы можете ознакомиться с другими примерами с сайта и, возможно, придёте к выводу, что U++ не только более выразителен и лаконичен, но и вполне себе расширяем. Что касается эффективности, то и здесь есть чему на что посмотреть.
Алексей, не совсем понял, чем именно, с вашей точки зрения, я ввожу людей в заблуждение?
Тем, что из моей статьи не следует явного призыва пользоваться готовым решением для моделей потоков с очередями? И что некоторые сделают вывод, что её лучше сделать самому?
С критикой согласен. В некотором роде, комментарии немного «вправили мозги» (в этом смысле, считаю что вообще очень полезно на Хабр выкладывать свои наработки).
В защиту лишь могу сказать, что с моей точки зрения основную ценность статьи представляет собой не реализация передачи сообщений (о которой было сказано не так много), а тот факт, что я поставил на повестку дня использование иных моделей, кроме shared memory. Я постарался показать, как при этом, добавив определённые ограничения на код, избавиться от объектов синхронизации.
В этом смысле, для человека, профессионально разбирающегося в вопросе, статья интереса не представляет. Скорее, я проблематизирую «конвейерный» (communicating sequential processes) подход для тех, кто не знает что это такое либо не представляет его потенциальные плюсы. Причём пишу с позиции примерно пяти лет практического использования в production, то есть некоторого понимания плюсов и минусов. То что получилось, действительно вдохновило меня рассказать об этом людям, именно с точки зрения практики. Потому что, всё-таки, ещё одна заумная статья на тему теории массового обслуживания, применённой к работе потоков, вряд ли кому-то здесь была интересна.
Жёсткий такой оффтоп, уважаемый Алексей.)
Насчёт «тут же появились» можно поспорить — нижний порог радаров (порядка десятков метров) имеет под собой определённые основания.
И насчёт конкурентов — тоже спорно, учитывая что очень многие хотят, но не могут.
Вот скажем, например, как сделали системы с разделяющимися боеголовками, так вот уже несколько десятков лет эффективного симметричного ответа не существует.
Предлагаю замять для ясности и просто порадоваться тому, что такое уникальное и красивое «чудище морское» было сделано нашими с Вами отцами первыми в мире.
«Статью не осилил»
— Что помешало, если не секрет? Старался разбавить статью картинками и не слишком усложнять (хотя было желание ввести теорию).
По поводу транспортного средства. Это экраноплан. Придуманные в первые десятилетия существования СССР (как и многие другие уникальные изобретения, вроде атомной электростанции или гироскопического шаропоезда), они могли развивать скорость в сотни километров час и двигаться над водой при волнении до 3 баллов (некоторые — больше). Фактически уничтоженная из-за предательства советской партийной элиты, индустрия экранопланов могла бы не только спасти большое число жизней, но и обеспечить полное доминирование нашей страны на морях. Насколько я знаю, до сих пор не существует тактических средств не то что уничтожения экранопланов, но и даже адекватного определения местонахождения.
Сейчас фирмы вроде Боинг делают определённые робкие шаги в направлении экранопланов, так что заработанный «на излёте», в 70-е годы, приоритет, тает.
Данный экраноплан был назван на Западе «Каспийским монстром» за свои размеры, мощь, скорость и манёвренность. При невероятных для мореплавания скоростях, экранопланы исключительно безопасны и стабильны при передвижении.
Именно оттуда я и взял ассоциацию с названием статьи.
Посмотрел. К сожалению, данная библиотека не эквивалентна предложенному подходу. Дело в том, что библиотека фактически завуалировала работу с объектами синхронизацию, принципиально не разрешив их проблемы. Как можно видеть из примеров, там всё ещё возможны deadlock-и, а значит и все прочие «прелести» классической многопоточности.
С моей точки зрения, предложенный в статье подход более прост, менее перегружен синтаксисом, и что важнее всего — свободен от проблем взаимного ожидания.
Конечно, там есть свои проблемы, но они уже скорее «логического» порядка, не приводящие к «падению» и зависанию.
Про «серебряную пулю» — это Вы придумали, уважаемый mejedi. Я же писал совсем другое:
Ну и наконец, надо понимать, что любой подход не является панацеей на все случаи жизни. Например, основной поток высокопроизводительного веб-сервера — это задача из другой области.
Если у Вас нет проблем с объектами синхронизации, то я вполне допускаю, что Вам моя статья просто неактуальна. А соответственно и спор о её преимуществах изначально бесплоден.
Что касается таких вещей как кэш, то, в общем случае, это одна из тех задач, где классическая синхронизация подходит куда лучше очередей.
Безусловно, вещи близкие.
Тут вопрос немного в другой идеологии. В моём случае, очередь присутствует внутри класса-потока и явным образом нигде не фигурирует. Пользователь может лишь «запросить» у объекта-потока определённый его колбэк. Объектная мизонтропия, организованное взаимное недоверие, инкапсуляция, возведённая в жёсткое правило.
В этом смысле, Queue — питоновский аналог очереди в объекте-потоке. Кроме того, в случае С++ в очередь кладутся строго «облегчённые» колбэки с аргументами, что позволяет говорить об определённом уровне эффективности.
Повторюсь, идеологически то что Вы привели — очень близко, да.
Большое спасибо за ссылку. К сожадению, я об этой библиотеке не знал. На досуге обязательно посмотрю более пристальное. Также интересно будет сравнить быстродействие моей и их библиотек на различных платформах.
Возможно, вам имеет смысл с ними договориться объединить (с дублированием, например) ваши системы.
Мы не в детском саду собрались.
Есть «правила игры».
Есть протоколы УИК, которые подписываются ВСЕМИ участниками комиссии и копии которых есть у всех участников УИК. Эти протоколы передаются наверх и суммируются.
Всё что нужно сделать гражданам — это просуммировать данные с копий протоколов УИК самостоятельно.
Всего таких протоколов будет порядка 100 тысяч.
Просуммировав, можно будет понять, на каком этапе произошла фальсификация и кто несёт за неё ответственность. Можно будет выяснить реальные цифры проголосовавших. В общем, можно будет выдавать данные параллельно (а может даже и раньше) с тем, как их посчитает центризбирком.
И ничего тут волшебного нет. Надо просто оторвать задницу от стула и принять участие в открытом, гражданском расчёте голосов.
А не визжать о «волшебнике Чурове» и его отставке.
Потому что если человек ответственен за фальсификации, то его надо судить по закону РФ. А если он перед законом чист, то оставить на своём месте. В любом случае, надо помнить, что в демократическом обществе существуют не только законы, но и презумпция невиновности.
Обязательно расскажу о программе всем знакомым ребятам-наблюдателям.
Вот ссылка на описание. Посмотрите, пожалуйста, это ли Вы имели в виду, или нет.
Здесь мы говорим конкретно о коде на С++, а не о процессах. Поэтому я также уточняю конкретные требования к декомпозиции задачи на классы, а также уточняю обмена абстрактными сообщениями до передачи колбэков с копированием параметров (простым или разрушающим).
В комментариях мне написали, что я не единственный, кто изобретал этот велосипед. Параллельно со мной этим занимались как крупные компании вроде Интел, так и другие команды исследователей. Всего есть как минимум несколько библиотек, которые решают сходные задачи, но со своими особенностями.
Однако, не могу согласиться с ней применительно к U++. Вы можете ознакомиться с другими примерами с сайта и, возможно, придёте к выводу, что U++ не только более выразителен и лаконичен, но и вполне себе расширяем. Что касается эффективности, то и здесь есть чему на что посмотреть.
Тем, что из моей статьи не следует явного призыва пользоваться готовым решением для моделей потоков с очередями? И что некоторые сделают вывод, что её лучше сделать самому?
В защиту лишь могу сказать, что с моей точки зрения основную ценность статьи представляет собой не реализация передачи сообщений (о которой было сказано не так много), а тот факт, что я поставил на повестку дня использование иных моделей, кроме shared memory. Я постарался показать, как при этом, добавив определённые ограничения на код, избавиться от объектов синхронизации.
В этом смысле, для человека, профессионально разбирающегося в вопросе, статья интереса не представляет. Скорее, я проблематизирую «конвейерный» (communicating sequential processes) подход для тех, кто не знает что это такое либо не представляет его потенциальные плюсы. Причём пишу с позиции примерно пяти лет практического использования в production, то есть некоторого понимания плюсов и минусов. То что получилось, действительно вдохновило меня рассказать об этом людям, именно с точки зрения практики. Потому что, всё-таки, ещё одна заумная статья на тему теории массового обслуживания, применённой к работе потоков, вряд ли кому-то здесь была интересна.
Насчёт «тут же появились» можно поспорить — нижний порог радаров (порядка десятков метров) имеет под собой определённые основания.
И насчёт конкурентов — тоже спорно, учитывая что очень многие хотят, но не могут.
Вот скажем, например, как сделали системы с разделяющимися боеголовками, так вот уже несколько десятков лет эффективного симметричного ответа не существует.
Предлагаю замять для ясности и просто порадоваться тому, что такое уникальное и красивое «чудище морское» было сделано нашими с Вами отцами первыми в мире.
— Что помешало, если не секрет? Старался разбавить статью картинками и не слишком усложнять (хотя было желание ввести теорию).
По поводу транспортного средства. Это экраноплан. Придуманные в первые десятилетия существования СССР (как и многие другие уникальные изобретения, вроде атомной электростанции или гироскопического шаропоезда), они могли развивать скорость в сотни километров час и двигаться над водой при волнении до 3 баллов (некоторые — больше). Фактически уничтоженная из-за предательства советской партийной элиты, индустрия экранопланов могла бы не только спасти большое число жизней, но и обеспечить полное доминирование нашей страны на морях. Насколько я знаю, до сих пор не существует тактических средств не то что уничтожения экранопланов, но и даже адекватного определения местонахождения.
Сейчас фирмы вроде Боинг делают определённые робкие шаги в направлении экранопланов, так что заработанный «на излёте», в 70-е годы, приоритет, тает.
Данный экраноплан был назван на Западе «Каспийским монстром» за свои размеры, мощь, скорость и манёвренность. При невероятных для мореплавания скоростях, экранопланы исключительно безопасны и стабильны при передвижении.
Именно оттуда я и взял ассоциацию с названием статьи.
С моей точки зрения, предложенный в статье подход более прост, менее перегружен синтаксисом, и что важнее всего — свободен от проблем взаимного ожидания.
Конечно, там есть свои проблемы, но они уже скорее «логического» порядка, не приводящие к «падению» и зависанию.
Что касается таких вещей как кэш, то, в общем случае, это одна из тех задач, где классическая синхронизация подходит куда лучше очередей.
Поскольку библиотека является частью фреймворка U++, на неё распространяется лицензия BSD.
Тут вопрос немного в другой идеологии. В моём случае, очередь присутствует внутри класса-потока и явным образом нигде не фигурирует. Пользователь может лишь «запросить» у объекта-потока определённый его колбэк. Объектная мизонтропия, организованное взаимное недоверие, инкапсуляция, возведённая в жёсткое правило.
В этом смысле, Queue — питоновский аналог очереди в объекте-потоке. Кроме того, в случае С++ в очередь кладутся строго «облегчённые» колбэки с аргументами, что позволяет говорить об определённом уровне эффективности.
Повторюсь, идеологически то что Вы привели — очень близко, да.