Страниц: [1]
  Печать  
Автор Тема: processes sync.  (Прочитано 7116 раз)
longest
Участник
*
Offline Offline

Сообщений: 20


Просмотр профиля
« : Декабря 24, 2002, 05:37:00 pm »

читаем в документации по ядру "The Neutrino Microkernel":

"Another useful property of semaphores is that they were defined to operate between processes. Although Neutrino mutexes work between processes, the POSIX thread standard considers this an optional capability and as such may not be portable across systems. For synchronization between threads in a single process, mutexes will be more efficient than semaphores."

Т.е. это понимать как рекомендацию не использовать mutex в процессах в переносимых программах?
А как тогда относиться ко всем остальным функциям pthread_*?
Записан
longest
Участник
*
Offline Offline

Сообщений: 20


Просмотр профиля
« Ответ #1 : Декабря 27, 2002, 06:10:00 am »

спрошу по другому. читаем:
"In POSIX.1c UNIX, a mutex may optionally be intra-process only."
0)
А как быть тогда с condvar, которые в том числе предназначены и для
inter-process (значение PTHREAD_PROCESS_SHARED) и рука об руку идут с mutex?

Появились еще вопросы.
1)
у меня два процесса. Синхронизируются mutex-ом в том числе. Когда я прерываю один из процессов в теле критической секции, другой, который был блокирован на мутексе вываливается с
[1] + EMT trap             ./a8-flow  (core dumped)
что делать?
(кстати, иногда система виснет наглухо)

2) как мне менять в процессе выполнения задачи очередность ее разблокировки на convar или mutex? Например, в очереди на broadcast для condvar есть несколько задачь. Нужен эффективный способ. Сейчас я использую две нити в процессе с разными приоритетами и за счет этого добиваюсь нужной последовательности разблокровки. Нити приходится синхрить между собой, так что хочется чегото другого. Может менять приоритет задачи прямо на ходу? На сколько эффективен такой способ? Нужна производительность не хуже, чем способ с двумя нитками.

3) Мъютех был захвачен задачей. Есть ли способ перезахватить этот мъютекс, если задача, что им владела вывалилась по какому-либо сигналу? В rtx я этим активно пользовался, что бы "подхватывать" ресурсы упавшей задачи.
Записан
Landy
Jr. Member
**
Offline Offline

Сообщений: 65


Просмотр профиля WWW
« Ответ #2 : Декабря 27, 2002, 12:34:00 pm »


Когда я прерываю один из процессов в теле критической секции, другой, который был блокирован на мутексе вываливается с
[1] + EMT trap             ./a8-flow  (core dumped)
что делать?

Т к процесс вывалился в критической секции у ОС нет способа определить, на каком этапе это произошло и насколько глубоки изменения, поэтому нельзя откатить это назад, т к ОС не знает к чему это приведет(на то это и критическая секция)
Кстати, в разделе про документацию, книга упоминается
"Unix. Взаимодействие процессов" -  там эти вопросы как раз обсасываются
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #3 : Декабря 27, 2002, 03:13:00 pm »


Landy пишет:
Кстати, в разделе про документацию, книга упоминается
"Unix. Взаимодействие процессов" -  там эти вопросы как раз обсасываются

Книга, которую называет Landy:
"UNIX: взаимодействие процессов" - Уильям Стивенс (к сожелению, умерший в прошлом году),
http://qnx.org.ru/forum/viewtopic.php?topic=466&forum=12&31

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

P.S. Кстати, обратите внимание, что и в QNX, и согласно требованим POSIX в системе (библиотеках) представлены, например, семафоры (и другие механизмы синхронизации) и "в стиле" BSD, и SYSV. И "ведут" они себя по-разному.


[ Это Сообщение было отредактировано: Olej в 2002-12-27 12:37 ]
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 470



Просмотр профиля
« Ответ #4 : Декабря 27, 2002, 04:36:00 pm »


Olej пишет:

Книга, которую называет Landy:
"UNIX: взаимодействие процессов" - Уильям Стивенс (к сожелению, умерший в прошлом году..


Не в прошлом... В 1999-м.
Записан
longest
Участник
*
Offline Offline

Сообщений: 20


Просмотр профиля
« Ответ #5 : Декабря 27, 2002, 11:22:00 pm »


http://qnx.org.ru/forum/viewtopic.php?topic=466&forum=12&31

да я эту книгу уже давно хотел купить, как только прочел про нее в "источниках"


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

Интересно, а как звучал бы ответ если бы о этой книге ничего не было известно? Правда, это меня добило и я оторвал задницу сегодня и не смотря на дикие пробки проехался по книжным. Таки купил.


Записан
longest
Участник
*
Offline Offline

Сообщений: 20


Просмотр профиля
« Ответ #6 : Декабря 28, 2002, 02:42:00 am »


Landy пишет:
Т к процесс вывалился в критической секции у ОС нет способа определить, на каком этапе это произошло и насколько глубоки изменения, поэтому нельзя откатить это назад, т к ОС не знает к чему это приведет(на то это и критическая секция)
Кстати, в разделе про документацию, книга упоминается
"Unix. Взаимодействие процессов" -  там эти вопросы как раз обсасываются

нельзя откатить назад и поэтому сигнал аварийного завершения?
в rtx происходила разблокировка с соответсвующим кодом ошибки.
А я уже сам решал, на сколько это фатально.
Записан
longest
Участник
*
Offline Offline

Сообщений: 20


Просмотр профиля
« Ответ #7 : Декабря 30, 2002, 06:54:00 am »

Прогнал нехитрый тест из этой книги.
Меня продолжают интересовать простейшие IPC и их эффективность.
Результаты теста mutex для Solaris приведены в книге в табл. А.4.
(первая колонка - взаимные исключения POSIX)
А вот мои результаты для на RtP 6.0 (celeron 366..433) - время в секундах

P166MMX
1.17
2.36
3.5

UNIPROC kernel (and SMP kernel with 1 CPU the same)
0.28
0.56
0.85
1.13
1.41

14.7 (40 нитей)

то же, 2 CPU
0.29
1.4
5.93
9.51
11.82

46.56 (20 нитей)
81.17 (40 нитей)

как видно потребное время в случае двух процов для
двух и трех и более нитей "непотребно" .
В тесте с двумя процами значения достаточно сильно (15%) варьировались от запуска к запуску, поэтому брались средние.
Использование ThreadCtl(_NTO_TCTL_RUNMASK,0x01) ничего существенного не дало.
Интересно, что показала б rtp 6.2?...
Записан
Landy
Jr. Member
**
Offline Offline

Сообщений: 65


Просмотр профиля WWW
« Ответ #8 : Декабря 31, 2002, 04:41:00 pm »


longest пишет:
Прогнал нехитрый тест из этой книги.
Меня продолжают интересовать простейшие IPC и их эффективность.
Результаты теста mutex для Solaris приведены в книге в табл. А.4.
(первая колонка - взаимные исключения POSIX)
А вот мои результаты для на RtP 6.0 (celeron 366..433) - время в секундах

Интересно, что показала б rtp 6.2?...

А вот мои результаты на QNX 6.2
PII-350

1 100000
100000 0.033995

2 100000
200000 0.066990

3 100000
300000 0.100985

4 100000
400000 0.133979

5 100000
500000 0.167974

6 100000
600000 0.205968

7 100000
700000 0.245962

8 100000
800000 0.271958

9 100000
900000 0.313952

10 100000
1000000 0.347947

20 100000
2000000 0.697893

100 100000
10000000 3.969393

первая строчка <число нитей> <количество инкрементов счетчика для нити>
вторая строка < результат счетчика> < время в сек>
А это для Athlon XP 1600+

1 100000
100000 0.007999

2 100000
200000 0.016997

3 100000
300000 0.023996

4 100000
400000 0.031995

5 100000
500000 0.039994

6 100000
600000 0.048993

7 100000
700000 0.058991

8 100000
800000 0.063990

9 100000
900000 0.071989

10 100000
1000000 0.080988

20 100000
2000000 0.161975

30 100000
3000000 0.245962

40 100000
4000000 0.326950

50 100000
5000000 0.407938

60 100000
6000000 0.490925

70 100000
7000000 0.571912

80 100000
8000000 0.651900

90 100000
9000000 0.737887

100 100000
10000000 0.818875

1000 100000
100000000 16.516473

Использовались функции pthread_create,pthread_mutex_lock,pthread_mutex_unlock
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #9 : Декабря 31, 2002, 07:16:00 pm »

Уважаемые!
Вы бы ещё, кроме жонглирования цифрами, попробовали "словами" объяснить (или предположить) - какие это эффекты мы наблюдаем в QNX, и - хорошо это или плохо.

И с Новым Годом.
Всех.
Записан
longest
Участник
*
Offline Offline

Сообщений: 20


Просмотр профиля
« Ответ #10 : Января 01, 2003, 09:25:00 pm »


Olej пишет:
Уважаемые!
Вы бы ещё, кроме жонглирования цифрами, попробовали "словами" объяснить (или предположить) - какие это эффекты мы наблюдаем в QNX, и - хорошо это или плохо.
И с Новым Годом.
Всех.


Поздравляю всех сабскрайберов с скоропостижно наступившим НГ!
Всем кто еще кутит с девченками или бухает с пацанами скорейшего возвращения в строй.

Та-ак, о чем это там мы?.. (с трудом возвращаясь к теме

Объяснить пока не могу
Надеюсь что это глюк или правится идеологически.
Это не есть хорошо - это плохо.
Сказать, что архи плохо не могу только потому, что надеюсь, что это глюк или правится.
Записан
longest
Участник
*
Offline Offline

Сообщений: 20


Просмотр профиля
« Ответ #11 : Января 06, 2003, 09:20:00 pm »

да. глюк. вернее моя ошибка. намудрил я с Affinity.
как и следовало ожидать, если всем ниткам привязать один проц., то времена  правильные.
Значит, скорее всего мы наблюдаем кешевые эффекты и столь значительная доля задержки вносится при доступе к структуре мьютекса.
Т.е. на MP системе уже важна не только скорость работы с примитивом синхронизации, но и то, какой размер имеет его рабочая структура, которая добавляет общих данных к прикладной задече.
Отсюда банальный вывод - накладные расходы на сихронизацию наших модулей не уменьшутся при переходе на MP. Так же, не стоит доверять системе распределение по процам тесно взаимодействующих (rt)задач. Не успеваю я до другого проца достучаться, даже если он свободен в данный момент.
В результате мне пока придется использовать ту же схему работы, что я использовал и в rtx (к слову сказать, sync. примитивы там были побыстрей): для rt-задач один проц, для всего остального - другой.
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #12 : Января 13, 2003, 10:38:00 pm »


longest пишет:
Не успеваю я до другого проца достучаться, даже если он свободен в данный момент.

Как это может быть? Опиши, хотя бы качественно (на пальцах).
Записан
longest
Участник
*
Offline Offline

Сообщений: 20


Просмотр профиля
« Ответ #13 : Января 16, 2003, 06:40:00 am »


Olej пишет:

longest пишет:
Не успеваю я до другого проца достучаться, даже если он свободен в данный момент.

Как это может быть? Опиши, хотя бы качественно (на пальцах).


это я фигурально выразился имелся ввиду оверхед на синхронизацию:
У меня частота получения и обработки выборок ~10К в секунду.
Для синхронизации взаимодействия служебной проги и программных модулей (DSP и модули ввода-вывода) используются mutex и condvar.
Т.е. фактически реализованы два barrier с некоторыми нюансами.
Для 5 модулей-заглушек (только IPC без начинки) на 10К итераций потребное время 0.5 сек на одном проце. Что можно интерпретировать как 50% накладных расходов от цикла дискретизации. На двух процах уже более 100%. Т.е. КПД для данного компьютера для данной задачи стоновится равен нулю это и имелось ввиду под "не успеваю достучатся".

Кстати, семафоры оказались на 30% быстрее своей реализации через mutex & condvar. Barrier, наоборот медленней. Еще было замечено заметное (~20%) снижение скорости , если на блокировке (condvar например) конкурируют процессы с разными приоритетами.

QNX RtP 6.0 & QNX 6.1
Dual Celeron 366 & 433 MHz, 66 MHz Bus clock:
10000 Iterations, 10 Shared Processes.
__________________________________________________
CPU   | Mutex   | Cond   | Sem   | RW   | Barr   |
__________________________________________________
UNIPROC | ~0.03   | ~1.08   | ~0.7   | ~0.3   | ~1.2
SMP       | ~0.26   | ~1.9   | ~1.2   | ~5.6   | ~2.8
Private   | -    | -    | ~0.3   | -       | -
Записан
Страниц: [1]
  Печать  
 
Перейти в: