В пытались объяснить зачем вам нужен график и трафик.
Я тоже пользуюсь интернет-помощником, но мне ни разу не захотелось посмотреть на статистику потребления трафика. Зачем он мне на первой странице?
А если у пользователя безлимит? Или он просто не пользуется мобильным интернетом?
Я не утверждаю что ваш вариант хуже того, что есть сейчас, я просто хочу сказать что проектировать подобный портал нужно с учётом всех категорий пользователей. А вы проектиреуте его исходя так: «тут какие-то ненужные и непонятные мне функции — убираем, а вот этот график лично меня интересует больше всего, пусть на главной странице лежит».
Вот только ваша «реорганизация интерфейса» заточена именно под ваш сценарий использования. А между тем интернет-помощником пользуются с совершенно разными целями (например, многих совсем не интересует трафик).
Как не задавай, физические-то пикселы от этого не повернутся. А для текста горизонтальное сглаживание важнее вертикального.
Вообще, вроде раньше Windows не умела делать ClearType с неподходящим расположением субпикселей. Может сейчас уже научилась, но толку от этого всё равно не так уж и много.
Там не в ширине проблема а в субпиксельном сглаживании, которое возможно только вдоль горизонтальной стороны монитора. При портретной ориентации сглаживания по-сути нет и пикселей катастрофически не хватает — вот глаза и вытекают.
В последних HTC барабаны не просто крутятся, но ещё и имеют тенденцию останавливаться на кратных 15 минутам значениях. При этом с одной стороны не надо особо целиться, а с другой стороны есть возможность выставить точное время, если это вдруг потребуется.
+1
Насколько мне известно OpenVZ с удовольствием перенесли бы свои патчи в ядро и с успехом это делают (LXC во многом их работа). Только вот протолкнуть патч в ядро это весьма и весьма сложная задача, причём далеко не только техническая.
Согласен, оказывается в .NET модель памяти в этом месте более жёсткая чем в привычной мне Java. Впрочем, от этого число проблем синхронизации в вашем коде сильно меньше не стало.
Наверное, наибольшее значение имеют результаты для одного потока, а если в программе десяток потоков действительно постоянно борются за одну блокировку, то что-то здесь не так :-)
> Да неужели. А что будет если во время Peek, после проверки isEmpty, операция TryDequeue из другого потока считает последний элемент?
Вы делаете успехи :-)
Если в очереди что-то осталось, то будет всё нормально, а в случае пустой очереди может случиться NullReferenceException. Тест, показывающий это здесь. Проверял на mono-2.10.5. Надо им баг заслать, наверное.
> В общем нет, а в случае атомарных операций(подмена одного указателя), где данные валидны и до и после апдейта — все безопасно. Об этом кстати можно прочитать если пройти по ссылке, которую я дал.
Только если подмена указателя делается через Interlocked, иначе публикация ссылки вполне может произойти раньше чем обновление данных, несмотря на порядок выражений в коде. Почитайте уже наконец теорию, сколько можно объяснять базовые вещи.
Только вот Peek и Take разные операции. Take (достать элемент из очереди) меняет состояние.
А Peek в ConcurrentQueue.cs работает правильно без «интерлока» только потому, что об этом позаботились в методе Enqueue, правильно расставив Interlocked операции. В общем же случае «один пишет, многие читают» совсем не означает потокобезопасность.
Так что B08AH, озаботились бы вы хотя бы чтением теории перед тем как лезть в отнюдь не простую область lock-free алгоритмов.
Ну значит вам везло. Впрочем, тестирование всё равно не докажет что код корректен. Оно может лишь доказать что он некорректен.
В данном случае в его некорректности нет никаких сомнений.
Я тоже пользуюсь интернет-помощником, но мне ни разу не захотелось посмотреть на статистику потребления трафика. Зачем он мне на первой странице?
Я не утверждаю что ваш вариант хуже того, что есть сейчас, я просто хочу сказать что проектировать подобный портал нужно с учётом всех категорий пользователей. А вы проектиреуте его исходя так: «тут какие-то ненужные и непонятные мне функции — убираем, а вот этот график лично меня интересует больше всего, пусть на главной странице лежит».
весьма сильное и скорее всего не верное. С чего вы это взяли?
Вообще, вроде раньше Windows не умела делать ClearType с неподходящим расположением субпикселей. Может сейчас уже научилась, но толку от этого всё равно не так уж и много.
Насколько мне известно OpenVZ с удовольствием перенесли бы свои патчи в ядро и с успехом это делают (LXC во многом их работа). Только вот протолкнуть патч в ядро это весьма и весьма сложная задача, причём далеко не только техническая.
Вы делаете успехи :-)
Если в очереди что-то осталось, то будет всё нормально, а в случае пустой очереди может случиться NullReferenceException. Тест, показывающий это здесь. Проверял на mono-2.10.5. Надо им баг заслать, наверное.
Только если подмена указателя делается через Interlocked, иначе публикация ссылки вполне может произойти раньше чем обновление данных, несмотря на порядок выражений в коде. Почитайте уже наконец теорию, сколько можно объяснять базовые вещи.
А Peek в ConcurrentQueue.cs работает правильно без «интерлока» только потому, что об этом позаботились в методе Enqueue, правильно расставив Interlocked операции. В общем же случае «один пишет, многие читают» совсем не означает потокобезопасность.
Так что B08AH, озаботились бы вы хотя бы чтением теории перед тем как лезть в отнюдь не простую область lock-free алгоритмов.
В данном случае в его некорректности нет никаких сомнений.