Ситуации взаимной блокировки

В Википедии дается следующее определение взаимной блокировки: «Взаимная блокировка (англ. deadlock) — ситуация в многозадачной среде или СУБД, при которой несколько процессов находятся в состоянии бесконечного ожидания ресурсов, занятых самими этими процессами».

Взаимные блокировки носят, как правило, динамический характер: их проявление зависит от таких факторов, как действия пользователя, доступность сетевых сервисов, позиционирование головки жесткого диска, переключение задач в системе с вытесняющей многозадачностью и т.п.

Классический пример взаимной блокировки: первый поток (A) захватывает мьютекс M1 и следом мьютекс M2. Второй поток (B) захватывает мьютекс M2, а уже после этого – мьютекс M1. Взаимная блокировка этих двух потоков может произойти следующим образом: поток A захватывает M1, поток B захватывает M2, после этого оба потока «обречены»: ни поток A не может захватить M2, ни поток B не может захватить M1; попытки захвата мьютексов заблокируют оба потока.

Описанная взаимная блокировка произойдет только в том случае, если оба потока успеют захватить ровно по одному мьютексу. В противном случае потоки продолжат свое выполнение.

Данная ситуация очень распространена в сложных многопоточных системах. Как правило, мьютексы-участники расположены далеко друг от друга (в различных компонентах системы), и выявить участников взаимной блокировки оказывается достаточно сложно.

Некоторое время назад была опубликована статья «Интеграция Team Foundation Services с Git и другие новые возможности». Нас очень порадовало, что читатели проявили к ней живой интерес и прислали нам отзывы и вопросы. Мы учтем их в процессе совершенствования наших инструментов и услуг, так что следите за нашими новостями. В этой публикации хотелось бы рассказать, как разработчики могут начать использовать инструменты Git в Visual Studio и сервис Git в TFS.

От переводчика: Не смотря на то что оригинал данной статьи датирован январем 2009 года, она не потеряла актуальности и теперь. Я надеюсь что даже те, кто используют JavaScript не первый год, почерпнут для себя что-то полезное.

1. Используйте === вместо ==

В JavaScript существует два разных типа операций сравния: === / !== и == / !=. Считается хорошим тоном всегда использовать первую пару для сравнения.

“Если два операнда одного типа и значения, то === вернет true, а !== false”
JavaScript: The Good Parts

Здравствуйте!

Я — Фёдор furikuretsu Ананьев, веб-разработчик студии Hot Dot, и сегодня я дам несколько простых советов для тех, кто хочет сделать своё JS-параллакс-приложение очень и очень быстрым.

Конечно, в США ещё день веб-мастера не наступил, но к празднику в интернет-гиганте подготовились на отлично, со свойственным циничным чувством юмора (весть о закрытии YT на первое апреля это наглядно демонстрирует). Итак, встречайте: Google Blink — принципиально новый движок рендеринга для Google Chrome.

Серьезно, прекратите. Это пустая трата времени и сил. Поищите регулярку для проверки Email в Google, взгляните на нее — и захочется отойти подышать свежим воздухом. Вспоминается одна очень известная цитата:

Некоторые люди, сталкиваясь с проблемой, думают: «О, я воспользуюсь регулярными выражениями».
Теперь у них две проблемы.

Джэйми Завински, regex.info

В расширениях Хрома принято указывать версию скрипта в виде не более чем 4 чисел, разделённых точками, и величиной не более 32767 каждое и не начинающихся с цифры 0. Этого более чем достаточно, если в номер версии включены обычные данные: версия, подверсия, сборка. Если в версию хотим поместить дату в виде 3 чисел, то в наиболее удобной для чтения записи (версия.год.месяц.день) числа года, месяца и дня занимают 3 места из 4. На версию остаётся первое число (как более приоритетное перед датой), а на подверсию и минор ничего не остаётся. Задача: как расположить минорную версию, чтобы уложиться в формат, чтобы дата была читаемой, а версия с минором при сравнении 2 строк занимала правильное место в ряду версий? Кроме того, нужна процедура выделения даты и версии с минором из общей строки.

Согласно данным AppAnnie почти весь рост выручки от приложений за последний год пришелся на in-app purchases. Но вызвано ли это только с тем, что данная бизнес-модель стала очень популярной? Или имеет место быть гиперконцетрация выручки у топовых паблишеров, которые в большинстве своем предпочитают free-to-play модель?

Вероятно оба этих факта возымели свой эффект, но не стоит забывать, что по-мимо in-apps достаточно большой поток выручки генерирует модель подписок.

Если исключить разработчиков топовых приложений (тех, кто зарабатывает с приложения более $50 тысяч в месяц и имеет более 500 тысяч активных пользователей) окажется, что одним из важнейших аспектов стало привлечение пользователей и последующее их удержание. Тем более, что средняя выручка с одного активного пользователя довольно статична вне зависимости от модели монетизации.

Почему многие дизайнеры и проектировщики интерфейсов не используют скетчинг на бумаге, а сразу включают компьютер? Неужели метод бумажных прототипов сложный, долгий и дорогой? Возможно, менеджеры проектов предпочитают тратить бюджет на что-то другое…

Добрый день, в своей статье, хочу рассказать, всем известную практику разработки ПО — Continuous Integration или Непрерывная интеграция.
Чтобы сразу пояснить в чем особенность статьи объясню, что в нашей команде стояла задача построить единый процесс для всех наших проектов. А проекты у нас бывают как мобильные (iOS, Android) и веб (верстка, сервисы, сайты).

Я хочу описать историю одного заносчивого и самовлюбленного студента Академического Университета, коим я, конечно, не являюсь, но хорошо представляю его мысли и переживания. Будем называть этого студента, например, Шурик. На момент поступления Шурика в Академический Университет (АУ), согласно его программистскому резюме, он уже был экспертом в области алгоритмов. Он мастерски владел алгоритмом поиска в глубину, знал несколько методов сортировки массивов, и имел представление о двоичном поиске. Естественно, курс алгоритмов его не интересовал совершенно, да и вообще, мало чему можно научить программиста с пятилетним опытом. Программа теоретической информатики АУ его заинтересовала тем, что в темах по известным ему предметам было слишком много неизвестных ему слов. Но это же Питер, там они и бордюр то странным словом называют, вероятно, и для поиска в глубину красивых слов понавыдумывали. Он тщательно изучил слайды и видеозаписи курсов. Оказалось, что существует какая-то там информатика, которой Шурик не владеет в совершенстве. Шурик собрал книги, носки и пять лет опыта, и отправился в Питер на собеседование. Там он встретил людей, которые могут научить чему-то даже программиста с таким опытом. Это все рушило Шурикову картину мира, в которой знание информатики измерялось количеством написанных классов на C#.
Во время учëбы в магистратуре Шурик занимался исследованиями в области схемной сложности и области экспоненциальных алгоритмов. Это действительно очень интересно и, что не менее важно, полезно для поступления в аспирантуру.
На данный момент Шурик является счастливым аспирантом New York University, использует слово «поребрик», и с глубокой благодарностью вспоминает Академический Университет. А кафедра математических и информационных технологий АУ и сейчас ведет набор новых магистрантов, в частности, по направлению «теоретическая информатика».
Сейчас я передаю слово Шурику, который и расскажет об одном своëм исследовании.

Steam Box, игровая консоль компании Valve, скорее всего, будет продаваться с предустановленной кастомизированной версией Linux. На веб-сервере репозитория Valve уже начали появляться первые наброски будущей операционной системы.

Как говорит Майкл Ларабел, так называемый “Steam Box”, вероятно, будет поставляться с кастомизированной версией Debian или Ubuntu. Более всего логично ожидать выпуска операционной системы на Ubuntu Core. Конечно же, за основу будет взята версия LTS, с продолжительным периодом поддержки.

Владельцам сайта Phoronix намекнули, что существует репозиторий hometest, права доступа к которому были изменены на публичные несколько дней назад. В отличие от обычного репозитория Valve, содержащего лишь пакеты Steam и Steam Launcher, в этом есть обновления для Steam на Ubuntu 12.04.2 LTS, экспериментальные драйвера nVidia для Linux, экран загрузки для графического загрузчика Plymouth и новые нескучные обои.

Опыт вождения по дорогам Киева натолкнул меня на пару интересных мыслей. Все мы знаем, что на дорогах «куча идиотов». Ровно так же дело обстоит и в разработке – куда ни глянь, страшно на код взглянуть. Почему так происходит?

Я тут пишу одну эпическую мегахрень, которую хочу пропиарить на хабре. Эта штука типа распределенной социальной сети. Там есть ядра с api, которые общаются по некоторому стандарту и фронтенд. Особенностью сети является то, фронтенд живет «отдельно» от ядра, то есть сеть не имеет своего домена — берем html, ставим ссылку на любое ядро и получаем сеть, которая живет поверх сайта. Внешне это похоже на социальные плагины фейсбука — комментарии и лайки оттуда можно поставить на любую свою страницу — только вместо тегов fb-like используются мощные биндинги knockout.js + пользователь не ограничивается огрызками из комментариев и лайков — на сайт можно импортировать практически любой блок из сети и сделать почти любое действие. Фронтенд написан на тех же технологиях, которые юзер может использовать и дописывать на своей странице.

В результате образовалась техника, которая может быть интересна фронтендщику. Эту технику хочу разобрать в этой статье.

Расскажу про систему, которая встраивается на html-страницу через биндинги нокаута. Код живет в подключаемых виджетах, которые состоят из html-шаблонов с knockout-обвязкой. Виджеты могут быть вложены друг в друга. Все это использует require.js и живет в amd форме. Зависимости от внешней страницы сведены к минимуму, все библиотеки (jquery, knockout и плагины) используются только свои в локальном пространстве с namespace-ами. Для сборки кода используется r.js. Еще как крутые перцы напишем на базе бутстраповского диалога полноценный оконный менеджер — с нокаутом это как два пальца об асфальт…

Есть такая библиотека knockout.js. Она отличается от прочих хорошим туториалом для начинающих и кучей понятных рабочих примеров. Еще там стройная MVVM модель, декларативные связи и так далее.

Короче, если вы, как и я, поиграли с этой библиотекой, понаписали красивых формочек, и вам это понравилось, то все это дело захотелось применить на реальном проекте. И тут проблема — в реальном проекте формочек больше чем одна. А раз такие инструменты, то хочется single web page application и никак иначе. А делать один контроллер и все темплейты заверстывать на одну страницу тоже тупо и тормозно.

Под катом приведу основу своего сложного приложения. Само оно совсем не сложное, но модульное и допускает расширения, а темплейты и модели подгружаются динамически. Идея была подсмотрена в этой презентации — http://www.knockmeout.net/2012/08/thatconference-2012-session.html, код презентации выложен на github — https://github.com/rniemeyer/SamplePresentation — на базе этого кода будем писать свой.

Многие сотрудники работают на своих боссов, нежели на компанию или своих клиентов. В наше время бизнес пронизан менеджерами разных уровней, и сотрудники часто обнаруживают, что они, играя в политику, фокусируются на задачах, которые осчастливливают их босса.

В конечном итоге компании быстро забывают какие у них цели и бизнес-задачи — каждый сотрудник занимается в основном только решением текущих задач, не придавая значения тому, как они укладываются в общую картину.

Если вы заметили такое на вашем текущем месте работы, знайте, что в этом виновата иерархическая структура организации.

Устранив иерархическую модель в моем агентстве digital маркетинга Ciplex, мы создали компанию, в которой люди любят работать, и при этом сэкономили деньги. Удовлетворенность наших клиентов увеличилась, и улучшилось качество нашей работы. Наши сотрудники стали счастливее, клиенты удовлетворены, расходы снизились, в целом компания стала значительно лучше.

Далее описание того, как я это сделал.

Всем привет.
В этой своеобразной статье я хотел бы осветить вопрос эффективности труда в течение рабочего дня на позиции руководителя проектов (другого управленческого звена в IT).
Здесь не будет никакой аналитики в цифрах, выдержек из кучи книг по time managment'у, а лишь личный опыт и сухие выводы. Я не собираюсь изобретать велосипед на Ваших глазах, но надеюсь, что послужу неплохим примером.

Добро пожаловать под кат.

Здравствуйте, господа!

Я был достаточно приятно удивлен, когда узнал, что проект Ajax.org, именуемый Ace почти ни разу не упоминался на хабре. Ace — это веб-редактор исходного кода нового поколения. Он поддерживает уйму различных функций, среди которых: наличие режимов подсветки синтаксиса для более чем 60 языков программирования, поддержка сумашедшего количества цветовых схем из различных популярных IDE, функций, среди которых: широкая кастомизация, проверка синтаксиса для нескольких скриптовых языков. Так уж получилось, что эта статья скорее всего будет разносторонняя, т.е. содержать материал для веб-разработчиков и С++ программистов, которых я так успешно агитирую в сторону Qt. Итак, что вы можете прочитать в этой статье?

• Быстрый старт с Ace. Где я могу использовать Ace? Почему?
• Портирование Ace на Qt и обертка его API: How-To для создателей Qt5-based библиотек (таких как мой порт Ace — Novile

Сейчас позволю себе показать пару скриншотов example-приложения, которое использует мою библиотеку Novile:

Здравствуй, Хабрачитатель! Я работаю веб-дизайнером, и сегодня мы продолжим развивать тему, начатую в прошлой статье. А именно, поговорим о взаимодействии двух специалистов, которые обычно работают в связке, при создании сайтов. Статья посвящена дизайнерам и их некоторым типичным ошибкам при работе с макетами.



Перед вами 8 ситуаций, в которых будут участвовать web-дизайнер — Дмитрий, работающий в программе Photoshop, и верстальщик — Владимир. Эти два парня знают свое дело, но у них постоянно возникают конфликты, а иногда у одного из них возникает странное желание ударить другого монитором по голове. Впрочем, все мы цивилизованные люди и допустить такой развязки не можем. А потому сейчас мы разберемся в некоторых причинах конфликта этих двух бесценных специалистов.

Помните старые, добрые времена, когда Bitcoin стоил 30$ штука (это было всего месяц назад)?
Все это в прошлом. Обменный курс стал трехзначным, т.е. превысил 100$ за 1 BTC.

Месячный объем торгов — превышает 150 млн$, а размер денежной массы — впервые превысил 1 млрд $.

Сложность майнинга (подбора хэшей SHA256, необходимых для проведения платежей в системе — за что полагается часть эмиссии биткоинов) за последний месяц резко возросла — т.к. заказчикам наконец стали приходить специализированные компьютеры производства Avalon с процессорами, заточенными именно под расчет SHA256. Butterfly Labs же пока создать такую систему не смогла, хотя обещала поставки 7 месяцев назад и до сих пор принимает предзаказы.

Под катом — несколько фотографий майнера от Avalon.