?

Log in

No account? Create an account
программистское - Поклонник деепричастий [entries|archive|friends|userinfo]
Anatoly Vorobey

[ website | Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| English-language weblog ]

программистское [авг. 8, 2004|07:12 pm]
Anatoly Vorobey
[Настроение |irritatedirritated]



Библиотека GLib предназначена в том числе для использование в программах с несколькими тредами; она “MT safe” (multi-thread safe). Но, оказывается, под “MT safe” дорогие разработчики GNOME/GTK понимают вот что. Предположим, я работаю с какими-нибудь объектами для хранения данных, скажем, хэш-таблицами (GHashTable). Так вот, если в разных тредах работаю с разными хэш-таблицами, то это безопасно. А если я в разных тредах работаю с одной и той же хэш-таблицей, то я должен сам координировать доступ, и не допускать к ней два треда одновременно, иначе попортят мне все данные.

Что-то мне это “MT safe” не кажется очень safe.

Но хорошо; пусть так; но хоть бы где-то объяснили это нормально! В документации об этом ни слова, а в исходниках GHashTable написано только, что она “MT safe”. Откуда я должен знать, что доступ к хэш-таблицам надо закрывать мьютексами или замками? прочитать это в гороскопе, может быть?
СсылкаОтветить

Comments:
[User Picture]From: mkay422
2004-08-08 09:22 am
Locking scheme при МТ всегда лучше дизайнить самому; библиотеки, где попытались это сделать за тебя, зачастую очень неудобны и негибки в использовании; можно налететь на deadlock, когда твои локи с библиотечными перемешаются. Но в документации могли бы и указать.
(Ответить) (Thread)
[User Picture]From: avva
2004-08-08 09:25 am
Ага, это всё, чего мне от них было нужно: нормально объяснить. Я и не против сам locking дизайнить. Но если написано "MT safe" и больше ничего не сказано, то я это понимаю так, что никаких дополнительных телодвижений при работе с этой библиотекой мне самому делать не надо.
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: iratus
2004-08-08 09:35 am
T safe значит, как правило, что сама бибилиотека не содержит внутри себя глобальных или статических переменных и может вызываться из разных тредов без боязни попортить ее внутренний стейт. Но это совсем не означает что она внутри себя контролирует доступ к внешним данным переданным ей. Более того, как правило, библиотека не имеет понятия о том кто ее вызывает, из какого треда, и является ли вызывающий мультитредным вообще. Это задача того кто ее вызывает, правильно координировать доступ. Я понимаю, что это, возможно, раздражает, но нет никакой другой возможности.. и более того так работают вообще все библиотеки помеченный как "MT saf" Это есть фича языка С, в котором нету контроля доступа к данным и поддержки тредов на уровне синтаксиса языка.
(Ответить) (Thread)
From: oblomov_jerusal
2004-08-08 09:41 am
Это есть фича языка С, в котором нету контроля доступа к данным и поддержки тредов на уровне синтаксиса языка. Для контроля за доступом к данным иметь конструкции для этого внутри языка необязательно.
(Ответить) (Parent) (Thread) (Развернуть)
From: evan
2004-08-08 09:41 am
I think the thread-safety glib claims is just that it can be used with threads at all: there aren't any global data structures used with hash tables. (By contrast, you could imagine something like the error-reporting system, which involves registering "Quarks" (global integer identifiers mapping to strings), not being thread-safe.)

As someone else suggested, it'd probably be too heavyweight for each hash to have its own lock, especially because there are valid use cases where use of a hash is kept entirely within one thread.
(Ответить) (Thread)
From: evan
2004-08-08 09:42 am

now that i think about it, i could just check

http://cvs.gnome.org/viewcvs/glib/glib/ghash.c?rev=1.36&view=auto

searching for "lock" indicates they do lock around the (global) memory pool stuff, but nowhere else.
(Ответить) (Parent) (Thread)
[User Picture]From: dvv
2004-08-08 10:26 am
Это Ваши проблемы. "MT-safe" означит, что библиотека если и использует свои внутренние глобальные данные, то безопасным образом, и в разных threads можно без проблем использовать библиотеку с _разными_ пользовательскими данными. Это термин из multi-threaded окружения, дублировать объяснения в каждой библиотеке - бессмысленно. А контроль доступа пользовательских threads к пользовательским данным - _всегда_ обязанность пользователя. Гороскопов читать не надо, надо документацию читать. Скажем, в Солярисе - attributes(5).
(Ответить) (Thread)
[User Picture]From: avva
2004-08-08 10:43 am
Что такое "пользовательские данные"? Если речь идёт об opaque структуре, которую создаёт библиотека, удаляет библиотека, работает с ней только эта библиотека, память под неё выделяет/освобождает библиотека, а никто другой даже и не знает, как она устроена, и вся её жизнь контролируется только через библиотеку, не столь уж невероятно допущение, что библиотека сама контролирует к ней доступ. Да, я согласен, что мне не стоило считать так, не проверив, но всё равно думаю, что в документации стоило об этом написать. См. также эту ветку.
(Ответить) (Parent) (Thread) (Развернуть)
(Удалённый комментарий)
From: ex_ilyavinar899
2004-08-08 10:30 am
То же самое можно сказать и о glib (я хорошо знаю её устройство). Если ты два различных объекта используешь в двух различных потоках, ты safe, а если один объект в двух потоках - ты unsafe.
(Ответить) (Thread)
From: ex_ilyavinar899
2004-08-08 10:31 am
Тьфу, я знаю zlib , а не glib.
(Ответить) (Parent) (Thread)
From: tangodancer
2004-08-08 11:23 am
ili ia idiot ili tot kto pisal etot GLIB.Thread Safe eto imenno kogda s odnim obiektom v raznyx threadax!!!!Che za bred??????
(Ответить) (Thread)
[User Picture]From: dvv
2004-08-08 02:03 pm
Первое. Что такое thread safety для функций/библиотек - см. http://www.unix.org/whitepapers/reentrant.html
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: _under_score_
2004-08-08 01:50 pm
а вот у .NET в документации четко сказано: any public static members are thread safe. Any instance members are not guaranteed to be thread safe.

и никаких двоякочтений.

(Ответить) (Thread)
From: tangodancer
2004-08-08 02:14 pm
pardon a prichom zdes .Net?
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: glarker
2004-08-08 08:15 pm
>Откуда я должен знать, что доступ к хэш-таблицам надо закрывать мьютексами или
>замками? прочитать это в гороскопе, может быть?
Как, на счёт GLib Overview, например: "The general policy of GLib is that all functions are invisibly threadsafe with the exception of data structure manipulation functions, where, if you have two threads manipulating the same data structure, they must use a lock to synchronize their operation" (выделено мной)

RTFM :))
(Ответить) (Thread)
From: dovlet
2004-08-08 08:32 pm
А сколько времени и нервов сэкономили бы, сразу по возникновении проблемы синхронизировав доступ к объекту самостоятельно? От ошибок никто не застрахован. Ни авторы Glib, ни вы.
Было нечто отдаленно напоминающее вашу ситуацию, но с openssl, К счастью, решилось при первом же штудировании документации.
(Ответить) (Thread)
[User Picture]From: caseq
2004-08-09 01:44 am
Это нормально, остальные производители (MS, например) ведут себя точно так же. "MT safe" традиционно означает, что реализация не содержит внутренних статических объектов и нереентерабельных функций, а вовсе не то, что авторы занимаются серализацией доступа к объектам пользователя. Вообще, основная идея C++ состоит в том, чтобы не пытаться впарить пользователю то, что ему не надо -- в данном случае, если какой-либо контейнер на деле используется только в одном треде, нет смысла жертвовать производительностью ради того, чтобы сериализовать к нему доступ. Более того, в тех редких местах где создателям, к примеру, MS-овской RTL пришлось вставить свои блокировки, это стало излюбленным местом для дедлоков -- в любом коде где есть больше одного объекта синхронизации, дедлок рано или поздно случается, а уж когда блокировка неявная и является деталью реализации, шансы наступить на грабли резко растут. А в случае, когда пользователь реализует синхронизацию самостоятельно, у него больше шансов (1) сделать ее в адекватном, с точки зрения архитектуры и борьбы за производительность, месте и (2) не наступить на мину, заложенную разработчиком RTL.
(Ответить) (Thread)
From: (Anonymous)
2004-08-10 02:16 am

aga

E'to verno ne tol'ko dlja MS RTL, no dlja standartnoj biblioteki C++ (STL) v zelom.

Zato biblioteka ACE ( http://www.cs.wustl.edu/~schmidt/ACE.html ) daet vozmozhnost' peredat' locking policy object kak template argument. Vot tak vot.
(Ответить) (Parent) (Thread)
From: oblomov_jerusal
2004-08-10 02:37 am
Пример употребления thread_safe в смысле "делающий нужные запирания"
man unlocked_stdio:
Each of these functions has the same behaviour as its counterpart with‐ out the ‘_unlocked’ suffix, except that they do not use locking (they do not set locks themselves, and do not test for the presence of locks set by others) and hence are thread‐unsafe. See flockfile(3).
(Ответить) (Thread)