Доброго времени суток, уважаемые Хабраюзеры!

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

Рисунок 1 – Взаимная блокировка 1-го рода с участием сигнальной переменной.

В рамках этого поста мы рассмотрим проблемы, которые возникают при использовании сигнальных переменных, и покажем, как их можно избежать.

Доброе время суток, дорогие хабравчане! Данная статья является продолжением топика, и в ней хотелось бы начать обсуждение стадии создания требований. Если вы успешно справитесь с этой стадией процесса, вы получите отличный продукт, счастливых заказчиков и удовлетворенных разработчиков. В противном случае вам грозит непонимание, разочарование и разногласия.

Стадию создания или разработки требований условно можно разделить на 4 этапа.

20 апреля 2013 года на официальном Портале Наукограда Дубна появилась новость с устрашающим названием «Паводок развивается по самому тревожному сценарию». Вот небольшая цитата из нее:

На очередном заседании оперативного штаба Глава города В.Э. Прох сообщил: «К сожалению, паводок развивается по самому тревожному сценарию, идет очень мощный сброс воды с Иваньковского водохранилища. Сегодня вода подступила к критической отметке уровня – уже частично затоплены садоводческие товарищества, в т.ч. «Заря», «Заря -1», «Дубна», вода вплотную подступает к жилым домам. В таких условиях, с целью защиты населения, я вынужден был объявить режим чрезвычайной ситуации.

Думаю, вы поймете наше беспокойство, если я скажу, что именно в Дубне находится место, называемое Российским центром программирования, в котором, собственно, находится центр разработки нашей группы компаний и большая часть наших корпоративных ресурсов!

«Великих аналитиков взращивают, а не обучают. Для работы аналитиком требуется множество личностных черт, а не знаний каких-либо технологий. Стандартного обучающего курса или описания обязанностей такого специалиста не существует. В аналитики приходят из разных профессий, и, скорее всего, у всех новичков есть пробелы в знаниях и навыках»
Вигерс Карл «Разработка требований к программному обеспечению», 2004

Карл Вигерс написал свою книгу практически 10 лет назад, но ситуация не изменилась – настоящих аналитиков единицы.
Эта серия статей – для тех, кто собирается стать профессиональным аналитиком требований. Информация собрана из личного опыта, книги Карла И. Вигерс «Разработка требований к программному обеспечению», а так же из опыта других аналитиков из сети Интернет.

Доброго времени суток, Хабрапользователи!

Визуальная криптография [1] впервые была введена Мони Наором и Ади Шамиром в 1994 году [3]. Она используется для шифрования изображения или текста, представленного в виде изображения. Основная идея модели визуальной криптографии состоит в разбиении исходного изображения на несколько шифрованных («теневых» изображений, shadow images), каждое из которых не дает никакой информации об исходном изображении кроме, может быть, его размера (изображение – а-ля «белый шум»). При наложении шифрованных изображений друг на друга, можно получить исходное изображение. Таким образом, для декодирования не требуется специальных знаний, высокопроизводительных вычислений и даже компьютера (в случае, если распечатать теневые изображения на прозрачных пленках). В случае использования этого алгоритма в компьютерных системах, наложить все части изображения друг на друга можно используя логические операции AND, OR, XOR (или установив более высокую степень прозрачности в графическом редакторе). Данная технология обладает криптоустойчивостью за счет того, что при разделении исходного изображения на множество шифроизображений происходит случайным образом.

Здравствуйте, уважаемые Хабраюзеры!

Так сложилось, что это третий пост в блоге нашей компании, и, как и первые два, он посвящен вопросам многопоточного программирования и проблемам, которые при этом возникают. Получилось так неслучайно, ведь мы на собственной «шкуре» испытали, что ситуации, возникающие при написании многопоточных программ, невероятно сложны для отладки, так как во многом определяются динамикой работы программы на конкретной аппаратной платформе. Уверен, что большинство программистов сталкивались с ситуацией, когда программа, которая прекрасно работает на одном компьютере, на другом совершенно неожиданно начинает дедлочиться практически «на ровном месте».

Здравствуйте, уважаемые Хабраюзеры!

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

Рассмотрим простой пример использования сигнальной переменной:

struct timeval now;
struct timespec timeout;
gettimeofday(&now, 0);
timeout.tv_sec = now.tv_sec + 2;      // 2 sec
timeout.tv_nsec = now.tv_usec * 1000; // nsec

retval=0;
pthread_mutex_lock(&mutex);
while(!somethingHappens() && retval==0)
{
    retval=pthread_cond_timedwait(&condition, &mutex, &timeout);
}
pthread_mutex_unlock(&mutex);

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

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

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

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

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

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