Кстати, когда будете выбирать конкретный «костыль», работоспособность и отсутствие побочек как-бы не гарантировано и лучше сначала пробуйте варианты «с малой кровью».
Если уж дать волю «грязным фантазиям», то вот вам еще один вариант «хентая с блекждеком и тентаклями»: если ваш роутер не умеет «несколько внутренних ip», то к вышеуказанному варианту с маской 255.255.255.254 на хосте, параллельно сажаете в локалку apr-спуфер, который отдавал бы mac-адрес роутера.
Вопрос не в том, справится или не справится. Вариантов решения можно еще напридумать, но ВСЕ эти варианты будут называтся словом «Костыли».
Вот вам еще экспонат в «коллекцию костылей»: Такой же эффект как port based vlan будет иметь, например, присвоить роутеру нескольких внутренних IP-шников и использовать на хостах сетевую маску 255.255.255.254. Т.е. так каждый из хостов мы заставим думать, что в одном с ним сегменте локальной сети, есть только он сам и роутер, и больше никого.
Да, если хорошо подумать, можно придумать еще парочку «решений», но если Вы ждете и надеятесь, что кто-то Вам предложит «Не-Костыльный вариант», то увы, вынужден Вас разочаровать ;( Как гласит поговорка, придется «выбор меньшего из зол»;(
По параметрам монтирования: из того, что больше всего влияет на производительность — опция noatime. Если у вас куча файлов и большинство операций доступа к файлам происходит на чтение — то может ускорить существенно.
Если у вас X11 forwarding тормозит на гигабитке с rtt 0.5ms то у меня смутные подозрения, что у вас тормоза все-таки где-то в другом месте. Ежедневно (в том числе в настоящий момент, лол) сижу через x11forwarding на 100mb локалке и даже не чувствую отдаленных намеков на тормоза. Да, наверное, в полноэкранное hd-видео не посмотришь и в 3д-шутер через форвардинг не поиграешь, но для работы даже нет намека на дискомфорт.
Другой поток-таки запись увидит, и гарантией выступает такая «хитрая вещь» как «синхронизация кешей». Именно благодаря ей, когда одно из процессорных ядер «засирает кеш-линию», если другие ядра, к которых тоже была эта кеш линия в кеше, просто перечитывают новое значение. Если бы этого «гаранта» не было, многоядерные процессоры просто не могли бы существовать.
Собственно, барьер это «граница в машинном коде», через которую запрещается «перетаскивать» порядок чтения/записи. Вещь чрезвычайно полезная, поскольку иногда без нее правильность логики действительно нельзя гарантировать.
А *volatile* для таких совместно используемых данных действительно необходим, поскольку именно он заставляет перечитывать данные из кеша, вместо того, чтобы положить в регистр (на который синхронизация кешей не распостраняется, и соотвественно, поток, считавший переменную *в регистр* действительно никогда не увидит больше, что переменная была изменена другим потоком).
gribozavr, да в «общем случае», обращение на чтение к переменной которую пишет другой поток, это конечно «гонка». Но, в описанном случае, булевая переменная это всего лишь «флаг по которому завершается поток», соответственно, логике «просто негде нарушится» (если говорить про конкретный случай).
Но иногда стоит и перестраховаться, если вместо «тупого завершения работы потока» в один прекрасный день там, вместо завершения возникнет код, чувствительный к переупорядочиванию чтения процом. Так что, да, барьер желателен. Благо, перестраховаться можно, барьер — это достаточно «дешево» для проца.
Кстати, общее правило: «синхронизация» нужна только в том случае, если существует риск нарушения логики работы других потоков (т.е. в момент изменения структуры данных могут находится в противоречивом состоянии, оперирование с которым может нарушить правильную логику).
В Вашем же случае, когда «поток A только читает bool а поток B только пишет» в принципе нарушение логики невозможно (поскольку для «железных типов данных», вроде bool не существует такого состояния, которое, бы нарушило логику потока A).Вернее, нарушение логики потока A, конечно возможно, но только в единственном случае — если вы забыли «volatile» и поток A будет продолжать использовать считанное значение переменной, вместо перечитывания обновленного значения.
К великому сожалению, из «бинарных» есть только один язык, который «лишен недостатков С++» — это… собственно язык Си :)
Именно по-этому он так любим как Торвальдсом, так и теми, кто ориентирован на «качество», а не на «скорость генерации говнокода». Да, хотите чтобы «качественно» — разрабатывайте на старом-добром C.
Кстати, про подобное «положение вещей» даже сам Страуструп очень даже «в курсе» вот несколько его цитат об этом: «Си позволяет легко выстрелить себе в ногу; с C++ это сделать сложнее, но, когда вы это делаете, вы отстреливаете себе ногу целиком.», «Ограничение возможностей языка с целью предотвращения программистских ошибок в лучшем случае опасно»… Offtopic: Кстати почитайте раздел «С++» в сборнике цитат о языках программирования: http://habrahabr.ru/post/144632/ — разные люди излагают свой взгляд.
Собственно, вся «трагедия» заключается в том, что все так называемое «развитие языков программирования» последних лет пятнадцати это всего лишь соревнование в количестве «фич, считающимися крутыми и модными» приправленное «синтаксическим сахаром».
Не обижайтесь, пожалуйста, если я Вам сейчас скажу «жесткую правду жизни» (в крайнем случае считайте это не «нравоучением», а считайте хитрым GTD-методом): подумайте над тем, что всякий раз когда у Вас голова занята размышлением «почему Линус не любит С++», у Вас в данный момент просто не будет времени подумать над более насущным вопросом «а почему моя программа течет по памяти». Жестко, но «отрезвляет» от «витания в облаках».
В том-то и проблема «ООП головного мозга», что пока у Вас голова занята «умственной мастурбацией» «философским спором» вида что лучше «указатель на функцию» или «virtual member» с точки зрения «чистых теорий» (а для компилятора они различаются по сути одним переходом по указателю), в ней не остается места для более практических мыслей о том как реализовать поставленную задачу (например, найти где все-таки наконец «программа течет по памяти».)
Просто отбросьте «догматизм» вы сразу обнаружите, что не стоит отвергать «virtual members» на одном только основании, что «это все зло от лукавого Страуструпа». И одновременно с этим, вы перестанете бояться брать на себя «ручной контроль» там где он вам действительно необходим (а если у вас программа «течет» по ресурсам, это, простите за каламбур, означает, верный признак, что вы что-то где-то пустили «на самотек»). А еще несуществующая «церковь святого ООП» при этом не предаст вас «анафеме» за то что вы каждую функцию не оформили в виде отдельно класса.
Возвращаюсь к вашему вопросу «почему многие программисты в том числе Линус плюются от C++». Так вот, Пока вы «восторженно» пишете код, радуясь, как у вас это быстро и лего выходит, Вы, боюсь, ни одного из ответов на свой вопрос просто не поймете. Настоящее понимание «ответа на ваш вопрос» к вам придет, когда вы лично проведете десятки тысяч часов в мучительной отладке. Тогда поймете, почему поддержка и отладка c++ кода это реальный ад. А сейчас просто пробуйте набираться опыта, («набить шишек», так можно сказать).
Да, к сожалению, у Вас, оно самое (ООП головного мозга), причем в очень запущенной стадии.
Простой критерий «запущенности заболевания» — если раздумывая над задачей, у Вас в голове вместо собственно мыслей о решении задачи у вас «из всех щелей лезут» мысли о «построеннии иерархии классов» — вам срочно нужно спасать свой мозг!!!
С точки зрения правильного посторения архитектуры — посмотрите, например, реализацию vfs или сетевой архитектуры в ядре — это для общего развития.
Из прикладных highload вещей с правильной модульной архитектурой (опробованных в продакшене) — рекомендую глянуть исходники nginx.
А из glib-а вы взяли наверное самый худший кусок (не учитесь плохому).
Вообще-то, если учесть что Σ«баланс» = Σвнесенной предоплаты — Σфактически оказанных услуг. Поэтому ничего удивительного. Оператор просто возвращает вам часть неизрасходованной предоплаты.
У вас какой квант «запуска по расписанию»? Если например, минута или тем более час, то сделать наступление момента времени «событием».
Впрочем, я бы рекомендовал вам все-таки подумать над «бюджетным» подходом. Необязательно выносить это сразу в пользовательский интерфейс (хотя, если бы вы это так сделали, я думаю пользователи были бы довольны), вы можете расчитывать «бюджет сообщения» например на ближайший запуск.
Даже очень хорошо вписываются. Только не говорите мне что у каждого пользователя по миллиону обьявляений и по каждому из них они каждую секунду меняют расписание. Я просто не верю что юзерам делать больше нечего, как каждую секунду менять расписание включений/выключений.
Очень похоже что вы сами себе и своим пользователям просто усложняете жизнь.
Если если время включения-выключения у вас зависит от погоды на марсе, то по крайней мере в такой системе должнен быть такой параметр как «бюджет обьявления». И все. Добавляете параметры «дневной бюджет»,«недельный бюджет»,«общий бюджет» для каждого обьявления и не смотря на время просто вычисляете достижение бюджета по факту размещения.
да, и еще попытка вести «помилисекундную тарификацию» это конечно выглядит круто… но на практике это всего лишь плюс к вашему ЧСВ. разумный «квант» тарификации например почасовая или поминутная тоже сильно облегчит вам жизнь.
У обьявления добавляете аттрибут «дата до которого оно размещено». Во-первых, для самого пользователя это добавит элемент прозрачности и управляемости, что всяко гут. А во-вторых, с вас снимет Кучу гемороя. В третьих, в этом ключе даст возможность правильного взаимодействия.
