Электронный миссионер

Ересь!
Искать нужно используя лозу!
Ну или на крайняк - вогнутую проволоку! %))

From:

В смысле?
В определённом месте проверить событие и стопнуться или тормознуть исполнение невзирая на то что сейчас выполняется?
Если второе - это сигналы смотреть нужно.

А вообще нужно больше деталей чтобы понять что и как делать.

Edited Date: 2014-01-27 09:07 pm (UTC)

From:

di-halt.livejournal.com

Почитай русский перевод документации по Salvo Rtos там писали не наркоманы. Еще книгу "Современные операционные системы" Танненбаума рекомендую.

From:

Сигналы не канают, т.к. нужно чтобы основной поток продолжал работать. Есть некоторая функция, которая шлёт данные на дисплей по таймеру. Если мы ловим события в основной программе, то нужно стопануть функцию показать менюшку, если юзер всё сделал, то продолжить слать данные. Функция посылки была сначала сделана алармом по таймеру, сейчас отдельный поток с задержкой

From:

Мне надо чтобы api линукса было, нафига мне ртос?

From:

di-halt.livejournal.com

Так тебе принцип не понятен или конкретная реализация?

From:

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

From:

sinclair-sc.livejournal.com

Из графитовых нанотрубок пойдут?

From:

Это всё понятно, КАК это сделать? Пример кода? Интересует блокировка

From:

Реализация

From:

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

Как вариант - отрисовка меню - в критической секции, окружаем ее мьютексами. Пока рабочий процесс занимается отрисовкой, управляющие не может слать данные. Т.е., грубо говоря, я это так вижу, в метокоде:

sem dataSend;
mutex dataInProcess;

управляющий:

mutex.lock(dataInProcess);
(...send to buf...)
mutex.unlock(dataInProcess);
sem.signal();

рабочий:

for (;;)
{
...if (sem.acquire(timeout)
...{
......mutex.lock(dataInProcess);
......(...read from buf...)
......mutex.unlock(dataInProcess);
...}
...(...draw...)
}

upd. жежешечка табуляцию порезала, но, я думаю, суть ясна

Edited Date: 2014-01-28 05:36 am (UTC)

From:

Ниже уже написали.

Ну или если код примерно такой:

while(true)
{
sleep(T);
send_data();
}

То достаточно send_data внутрь блокировки взять:

while(true)
{
sleep(T);
mutex_lock()
send_data()
mutex_unlock();
}

А в обработчике события тоже самое:
{
mutex_lock();
show_and_work_with_menu();
mutex_unlock();
}

ЗЫ. Вроде ж в литературе все есть? Взять например "Теренс Чан - Системное программирование на C++ в Unix" вполне понятно написано как по мне. Или вот Стивенс У. UNIX. Профессиональное программирование. (http://padabum.com/d.php?id=16369) Вторая пожалуй даже получше будет.

Edited Date: 2014-01-28 06:10 pm (UTC)

From:

По сути так и сделал, вот код:

void *show_current_track() {
	while (1) {
		pthread_mutex_lock(&mutex);
.... Некий код, который нельзя прерывать ...
		pthread_mutex_unlock(&mutex);
		usleep (500000);
	}

...

И далее в другой функции делаю так:

void tuning_action() {

....
	pthread_mutex_lock(&mutex);
       тут код, который исполнится когда у нас будет пауза

From:

Тег <pre> и его закрытие. Спасибо, я примерно так и сделал http://dlinyj.livejournal.com/640648.html?thread=8363656#t8363656 . Пытался написать тебе на мыло, ругается гмайл...

Edited Date: 2014-01-28 07:39 pm (UTC)

From:

Тут надо бить по рукам. Мьютексы нельзя использовать для обработки длительных событий - только для критического кода. Для остальных случаев - event, semaphore, message и т.п.

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

From:

Спасибо, про тег не знал.

alexeyk13 на яндекс.ру

From:

Только добрался до ЖЖ. Можно не ругаться, а дать пример как надо делать? И объяснить почему так...

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

From: