Pthread & NetBSD

Jan 03, 2003 02:46

Оказывается, реализация libpthread в NetBSD достаточно странно реагирует на некритические ошибки в работе библиотеки. Допустим, когда разблокируется незаблокированный мьютекс или же разблокируется не мьютекс, а мусор, libpthread зовет по умолчанию abort. Имхо, в release такого быть все же не должно. Ну, наткнулась на ошибку -- возврати -1 или еще ( Read more... )

Leave a comment

Comments 9

dbg January 4 2005, 22:20:01 UTC
Вот как раз на этом типе ошибок (разблокирование незаблокированного мьютекса, мьютексные операции над мусором и т.п.) abort - единственно правильная реакция, т.к. такие действия программы однозначно свидетельствуют об ошибке программирования. А возвращать -1 бесполезно, все равно никаким вменяемым способом такую ошибку не обработаешь. Fail early, fail often - очень правильная стратегия для подобных вещей. А отрубание проверок проблем не решает - оно из только маскирует.

Reply

cebka January 4 2005, 22:35:35 UTC
Разблокирование незаблокированного мьютекса - ошибка, как мне кажется, некритичная. Нам ведь никто не запрещает просто убедиться, что мьютекс у нас точно не заблокирован. Насчет передаче библиотечной функции мусора я считаю, что по умолчанию она должна не рушить работу всей программы, а аккуратно, как, например, функции libc, возвращать ошибку (я, конечно, понимаю, что использование errno в multi-thread окружении - не слишком удачная идея). Так происходит во FreeBSD. Например, тот же oops там не падает. Хотя, конечно, оставить возможности для отладки хорошо. Кстати, в malloc в FreeBSD тоже есть некий набор отладочных операций, однако, по умолчанию они отключены. Я не спорю с тем, что вышеописанные операции являются ошибками программирование, но делать их абсолютно фатальными для всего процесса (а не треда, к примеру), имхо, неверно.

Reply

dbg January 4 2005, 22:44:25 UTC
Ну смотри, вернул pthread_mutex_unlock в качестве реакции на мусор -1/errno==EINVAL (ничего страшного в использвании errno в многониточных программах нет, в таком контексте errno - макрос для соответственного thread local кусочка памяти). И чего? И что ты будешь с этим делать?

Reply

cebka January 4 2005, 22:55:29 UTC
Про errno согласен, забыл, что есть глобальная и локальные для тредов errno. А насчет обработки ошибок, я думаю, это задача не библиотеки, а программы их обрабатывать. Допустим, malloc при невозможности выделить память тоже возвращает NULL, следуя твоей логике, получаем, что он должен был сделать abort.

Reply


cebka January 5 2005, 14:22:45 UTC
Благодаря maxim, который мне указал, что нужно возвращать не errno,а результат работы pthread_mutex_unlock, я прогнал этот тест на самых разнообразных реализациях pthread. Судя по спецификации IETF pthread_mutex_lock вызывает то, что текущая нить становится владельцем мьютекса, то есть, pthread_mutex_unlock на незаблокированный сокет должен вызывать EPERM. В итоге имеем:
FreeBSD 5.3 + kse == EPERM
FreeBSD 5.2.1 + c_r == EINVAL
Linux on PA-RISC == 0
Tru64 Unix 5.1 == 0
NetBSD 1.6.2 + gnu pthreads == EDEADLK

Осталось добраться до Москвы и прогнать этот тест на интересующей меня NetBSD 2.99.11 + native threads. Что, впрочем, произойдет уже завтра.

Reply

cebka January 6 2005, 07:48:48 UTC
$ ./thread-test
thread-test: Error detected by libpthread: Unlocking unlocked mutex.
Detected by file "/usr/src/lib/libpthread/pthread_mutex.c", line 345, function "pthread_mutex_unlock".
See pthread(3) for information.
Abort trap (core dumped)

(gdb) bt
#0 0x4808d2c3 in kill () from /usr/lib/libc.so.12
#1 0x4806b951 in pthread__errorfunc () from /usr/lib/libpthread.so.0
#2 0x48068b3f in pthread_mutex_unlock () from /usr/lib/libpthread.so.0
#3 0x080487d5 in main ()
#4 0x080485e6 in ___start ()

$ uname -v
NetBSD 2.99.11

Вот так.

Reply


Leave a comment

Up