Форум: "Прочее";
Текущий архив: 2009.05.17;
Скачать: [xml.tar.bz2];
ВнизAnsiString и его изменение потокобезопасно? Найти похожие ветки
← →
It's not me (2009-03-10 19:10) [0]Имеем процедуру у некоторого класса:
procedure TMy.AddOpenDev(NewDev: string);
begin
FOpenDev := FOpenDev + NewDev + "|" ;
end;
также имеем:type
TCallbackOpen = procedure(NewDev: string) of object;
Если разным потокам давать TCallbackOpen в виде AddOpenDev, это будет являться потокобезопасным?
На практике вроде работает тестово, но потоки вещь такая... Кто знает точно?
А плодить крит. секцию для работы с одной строчкой лениво. так что хочется знать правду )
← →
DVM © (2009-03-10 19:13) [1]
> AnsiString и его изменение потокобезопасно?
нет
← →
Игорь Шевченко © (2009-03-10 19:22) [2]Мало информации
← →
Тимохов © (2009-03-10 19:25) [3]
> DVM © (10.03.09 19:13) [1]
> > AnsiString и его изменение потокобезопасно?
> нет
смотря как смотреть:
В смысле не будет Access Violation (т.к. строка не станет инвалидной - у них там все продумано в этом плане), но результат вообще говоря не известен :)
автор, юзай крит. секцию.
← →
Сергей М. © (2009-03-10 20:35) [4]
> It"s not me
Вот тебе сейчас дашь инф-цию к размышлению, а ты опять тут гнусавить будешь)
Тебе не надоело, а ?
← →
тест(забыл пароль) (2009-03-11 07:26) [5]It"s not me (10.03.09 19:10)
Что за переменные ты используешь?
Область видимости у них какая?
Если взаимодействие потоков(нитей)?
Взаимодействие потоков(нитей) между собой как происходит?
Код полностью выложи тогда будет понятно про что речь, пока что код ни про что не говорит.
← →
KSergey © (2009-03-11 08:42) [6]> Игорь Шевченко © (10.03.09 19:22) [2]
> Мало информации
А что еще надо уточнить?
← →
It's not me (2009-03-11 09:55) [7]Игорь Шевченко © (10.03.09 19:22) [2]
Мало информации
что именно не хватает?
тест(забыл пароль) (11.03.09 7:26) [5]
Что за переменные ты используешь?
FOpenDev это приват член класса TMy. Класс TMy умрет позже, чем все потоки, которые могут использовать TCallbackOpen, естественно. Вопрос про то, что будет если два разных потока в одно время будут пытаться модифицировать переменную типа string показанным образом.
тест(забыл пароль) (11.03.09 7:26) [5]
Если взаимодействие потоков(нитей)?
какая разница и что ты называешь взаимодействием потоков?
тест(забыл пароль) (11.03.09 7:26) [5]
Код полностью выложи тогда
кода слишком много, чтобы выкладывать.
← →
Дмитрий С (2009-03-11 11:01) [8]То что ты привел точно потоко-НЕ-безопастно. Причем тут даже AnsiString не причем, так даже с Integer-ом делать нельзя.
← →
Игорь Шевченко © (2009-03-11 11:22) [9]
> что именно не хватает?
Кода
← →
It's not me (2009-03-11 11:55) [10]
> так даже с Integer-ом делать нельзя
с integer"ом нельзя, я знаю. Но почему отсюда следует, что так нельзя делать с AnsiString - не понимаю.
> Кода
ну вы не будете разбираться в килобайтах кодах. Смысл в том, что отдельные потоки пытаются открыть некие устройства (ну допустим, COM-порты для наглядности), как только это получается - вызывают свой TCallbackOpen. Соответственно, момент открытия - произвольный, а TCallbackOpen у них у всех задан в AddOpenDev одного и того же экземпляра класса TMy. Внутренней синхронизации там нету.
Собственно, непонятно для чего нужен код. Фишка в том, что ссылку на функцию AddOpenDev имеют разные потоки и могут дернуть ее в любой момент, вот и вся информация.
← →
Игорь Шевченко © (2009-03-11 12:04) [11]It"s not me (11.03.09 11:55) [10]
> Смысл в том, что отдельные потоки пытаются открыть некие
> устройства (ну допустим, COM-порты для наглядности), как
> только это получается - вызывают свой TCallbackOpen. Соответственно,
> момент открытия - произвольный, а TCallbackOpen у них у
> всех задан в AddOpenDev одного и того же экземпляра класса
> TMy
Насколько я тебя понял, несколько потоков могут модифицировать одно и тоже свойство FOpenDev одного экземпляра класса, причем, каждый своим значением ?
В таком случае это вообще неверная идеология и никакая потокобезопасность и даже критическая секция тебя не спасут.
FOpenDev в этом случае должен быть свойством экземпляра класса, реализующего поток.
← →
Сергей М. © (2009-03-11 12:27) [12]
> могут дернуть ее в любой момент
Картина маслом - "Когда в товарищах согласья нет .." (С)(R) И.А.Крылов "Лебедь, рак и щука"
Тебе "лениво" КС заводить ? Заведи любой другой подходящий объект синхронизации.
И его тоже лениво ? Ну тогда закономерно будешь иметь "А воз и ныне там", причем разорванный в клочья)
← →
oxffff © (2009-03-11 12:29) [13]
> FOpenDev := FOpenDev + NewDev + "|" ;
> В таком случае это вообще неверная идеология и никакая потокобезопасность
> и даже критическая секция тебя не спасут.
Не хорошо давать свои субъективные оценки, тем более вслух и как всегда без разъяснения.
И тем более что они некорректны.
Могу еще пустой try except припомнить.
Теперь по делу:
Не о чем не говорит?
Это список через разделить всех открытых устройств.
To автор
FOpenDev := FOpenDev + NewDev + "|"
Проблема этой строчки в том, в момент FOpenDev + NewDev, FOpenDev может не существовать или быть в другом месте из-за работы другого потока.
Если на одну и туже строчку ссылаются несколько переменных,каждая в своем потоке, то работа с ними безопасна в кажом их потоке.
А работа с разделяемой не защищенной ссылкой обязательно приведет к ошибке.
Простой пример
1 поток. Получили ссылку
1 поток начали чтение
2.поток Грохнули ссылку
1 поток Продолжаем чтение, но недействительной сслыке
← →
KSergey © (2009-03-11 12:32) [14]> Игорь Шевченко © (11.03.09 12:04) [11]
> и даже критическая секция тебя не спасут.
> FOpenDev в этом случае должен быть свойством экземпляра класса, реализующего поток.
Почему? Я не понимаю. Ну если не рассматривать случай, когда экземпляр TMy еще не сконструировался, а потоки уже поперли выполняться.
По сути (как я понимаю) это обычный этакий логгер, синглтон.
← →
Игорь Шевченко © (2009-03-11 12:34) [15]oxffff © (11.03.09 12:29) [13]
> Не хорошо давать свои субъективные оценки, тем более вслух
> и как всегда без разъяснения.
Давай свои, кто мешает ?
> Могу еще пустой try except припомнить.
Конечно можешь - я еще в той теме говорил, что ты сам можешь писать как угодно и что угодно, можешь даже проповедовать свой стиль написания на форуме, но оставь за другими право на их точку зрения.
Доступно ?
← →
oxffff © (2009-03-11 12:36) [16]
> Игорь Шевченко © (11.03.09 12:34) [15]
Доступно.
← →
clickmaker © (2009-03-11 12:54) [17]> procedure TMy.AddOpenDev(NewDev: string);
> begin
> FOpenDev := FOpenDev + NewDev + "|" ;
> end;
тут задумался... а что происходит при закрытии девайса?
← →
It's not me (2009-03-11 12:56) [18]
> Насколько я тебя понял, несколько потоков могут модифицировать
> одно и тоже свойство FOpenDev одного экземпляра класса,
> причем, каждый своим значением ?
Игорь, перечитайте пример в первом посте!
Есть экземпляр класса TMy. Он стартует раньше всех "рабочих" потоков и умирает после завершения всех "рабочих" потоков. Каждый из рабочих потоков получает в виде TCallbackOpen ссылку на функцию:
procedure TMy.AddOpenDev(NewDev: string);
begin
FOpenDev := FOpenDev + NewDev + "|" ;
end;
этого экземпляра класса.
Ну примитивно все выглядит так - стартуют потоки, они знают указатель на функцию, которую нужно дернуть, когда у них получится сделать нечто. Это ссылка на метод одного экземпляра класса TMy. Соответственно .как только потоком удается выполнить это нечто, они дергают этот метод. Сама реализация метода представлена.
Вопрос только в том, есть ли в ansistring встроенная синхронизация или нет. Я слышал, что там хитро все устроено, но не знаю насколько хитро. Видимо, синхронизациии нету... Придется одна эту строчку по контектации строки (или как это правильно называется :) ) оборочивать в синхронизацию )
← →
Игорь Шевченко © (2009-03-11 13:08) [19]It"s not me (11.03.09 12:56) [18]
> Игорь, перечитайте пример в первом посте!
> Имеем процедуру у некоторого класса:
>
> procedure TMy.AddOpenDev(NewDev: string);
> begin
> FOpenDev := FOpenDev + NewDev + "|" ;
> end;
>
> также имеем:
>
> type
> TCallbackOpen = procedure(NewDev: string) of object;
>
> Если разным потокам давать TCallbackOpen в виде AddOpenDev,
> это будет являться потокобезопасным?
Вот первый пост целиком.
> Есть экземпляр класса TMy. Он стартует раньше всех "рабочих"
> потоков и умирает после завершения всех "рабочих" потоков.
> Каждый из рабочих потоков получает в виде TCallbackOpen
> ссылку на функцию:
Это из первого поста не следует.
Ты пойми простую вещь - проблема или вопрос у тебя, а не у отвечающих, поэтому в твоих интересах написать как можно больше (я не зря сказал, что мало информации) для того, чтобы никто из отвечающих не телепатировал и не додумывал за тебя, а что же тебе надо, возможно додумывая совсем не то, что ты имеешь в виду.
← →
It's not me (2009-03-11 13:12) [20]
> Ты пойми простую вещь - проблема или вопрос у тебя, а не
> у отвечающих, поэтому в твоих интересах написать как можно
> больше
как можно больше - я могу неделю сидеть описывать взаимосвязь всех классов и потоков внутри программы. Только читать это никто не будет в результате.
Я осветил проблему настолько, насколько мне кажется нужно, чтобы при обладании знаниями о string суметь ответить на вопрос. Если данных не хватает - задавайте уточняющие вопросы, я освещу в данном направлении тему. Рассказать тему полностью - нет никакой возможности и никому это не будет интересно.
← →
Игорь Шевченко © (2009-03-11 13:31) [21]It"s not me (11.03.09 13:12) [20]
> Я осветил проблему настолько, насколько мне кажется нужно,
> чтобы при обладании знаниями о string суметь ответить на
> вопрос. Если данных не хватает - задавайте уточняющие вопросы
Почитай, плз
http://ln.com.ua/~openxs/articles/smart-questions-ru.html
Еще раз - проблема у тебя, и в твоих интересах снизить количество уточняющих вопросов.
← →
KSergey © (2009-03-11 13:58) [22]> Игорь Шевченко © (11.03.09 13:31) [21]
> Еще раз - проблема у тебя,
Т.е. по делу о том, что крит. секции не спасут сказать нечего?
← →
Игорь Шевченко © (2009-03-11 14:15) [23]KSergey © (11.03.09 13:58) [22]
Да мне б узнать это дело. Возможно я неправильно понял автора, когда писал пост [11], но иметь дело с хранителями главной военной тайны я не хочу. Пусть сами мучаются.
← →
KSergey © (2009-03-11 14:19) [24]В [11] было безапеляционное заявление "крит. секции не спасут", без уточнения при каких условиях. Вот не спасут и все. Вообще. Никогда.
Видимо это не правда все ж? Так ведь?
← →
oxffff © (2009-03-11 14:21) [25]
> It"s not me (11.03.09 13:12) [20]
Мне полностью понятен твой вопрос и я дал тебе полный ответ на него.
см. [13]. Со слов To автор.
← →
KSergey © (2009-03-11 14:24) [26]> clickmaker © (11.03.09 12:54) [17]
> тут задумался... а что происходит при закрытии девайса?
"Ни шагу назад, ни шагу на месте..."
← →
Игорь Шевченко © (2009-03-11 14:25) [27]KSergey © (11.03.09 14:19) [24]
А я вроде как написал, что возможно неправильно понял ? И в [11] было указано, как я понял, и, соответственно, при этом понимании таки да, не спасут.
← →
test © (2009-03-11 14:32) [28]Автор ветки выложи наконец пример испоьзования этого чудо метода, пока что твой случай это [13].
← →
oxffff © (2009-03-11 14:47) [29]
> It"s not me (11.03.09 13:12) [20]
Этот вроде внешне безобидный код,
procedure DoBuggyCode(const Source:string;var Dest:string);
begin
Dest:=Source[1]+Source[2];
///////////
//Еще что-то
///////////
Dest:=Source[1]+Source[2];
end;
можно превратить в потенциально опасный простым вызовом.
DoBuggyCode(a,a);
← →
Skyle © (2009-03-11 14:54) [30]
> clickmaker © (11.03.09 12:54) [17]
> > procedure TMy.AddOpenDev(NewDev: string);
> > begin
> > FOpenDev := FOpenDev + NewDev + "|" ;
> > end;
>
> тут задумался... а что происходит при закрытии девайса?
А что тут думать...procedure TMy.RemClosedDev(ClosedDev : String);
begin
FOpenDev := StringReplace(FOpenDev, ClosedDev + "|", "", []);
end;
← →
It's not me (2009-03-11 15:28) [31]
> см. [13].
oxffff, я просто по посту [13] понял, что ты сам не очень точно знаешь, неуверенно отписао в стиле "может". Я сам понимаю, что в общем это МОЖЕТ привести к конфликтам. Но как конкретно устроены функции по работе со string не знаю.
Ты отписал, что:>Проблема этой строчки в том, в момент FOpenDev + NewDev, FOpenDev
>может не существовать или быть в другом месте из-за работы другого
>потока
то есть, получим AV. Хотя постом выше Тимохов уверенно сказал:>В смысле не будет Access Violation (т.к. строка не станет инвалидной - у
>них там все продумано в этом плане
из чего я сделал вывод, что ты до конца сам тонкостей реализации string"а не знаешь. Просто предположил возможные глюки. Я их точно также предположил, но точно не знаю, поэтому и завел ветку.
← →
test © (2009-03-11 15:39) [32]It"s not me (11.03.09 15:28) [31]
Если получишь AV это даже хорошо, но ты можеш получить взаимоисключающие команды, с ними ты делать что будешь?
← →
oxffff © (2009-03-11 15:55) [33]
> It"s not me (11.03.09 15:28) [31]
> из чего я сделал вывод, что ты до конца сам тонкостей реализации
> string"а не знаешь.
Поясни, как можно сделать такой вывод?
P.S.
Я тебе написал конкретный пример в [13] и [29].
Отсутствие AV не означает, что код корректный.
← →
KSergey © (2009-03-11 15:59) [34]> Игорь Шевченко © (11.03.09 14:25) [27]
> И в [11] было указано, как я понял,
> Игорь Шевченко © (11.03.09 12:04) [11]
> Насколько я тебя понял, несколько потоков могут модифицировать
> одно и тоже свойство FOpenDev одного экземпляра класса, причем, каждый своим значением ?
В такой постановке был выдан диагноз "не спасет никогда". Я с ним не согласен.
Ели я правильно понял дальнейшее, категоричность утверждения связана с предположением, что экземпляр TMy может быть не создан до старта потоков, однако сказано этого не было, а потому категоричность и однозначность вызывает у меня недоумение.
Ну либо я чего-то недопонимаю именно в указанной постановке.
← →
It's not me (2009-03-11 16:07) [35]
> Поясни, как можно сделать такой вывод?
я пояснил вообще-то. Давай еще раз:
Ты в посте [13] описал ситуацию, которая должна на мой взгляд привести к AV. (а что еще будет, если по твоим словам строчка может находиться уже в другом месте, чем думает один из потоков, в таком случае AV очень вероятен).
При этом Тимохов очень уверенно отписался, что AV уж точно не будет, типа в string все это продумано. И не уточнил что именно продумано.
Отсюда я сделал вывод, что ты сам не до конца знаешь тонкости реалзиации string, если фактически предположил то, чего быть не может.
← →
Игорь Шевченко © (2009-03-11 16:09) [36]
> В такой постановке был выдан диагноз "не спасет никогда".
> Я с ним не согласен.
Нет, категоричность утверждения была вызвана тем, что неизвестен собственно момент модификации, причем даже начала и окончания модификации, и нет гарантии, что один поток выполнит модификацию целиком, прежде чем другой поток не начнет такую же модификацию, в это время начнется чтение и прочитается неизвестно что. Писать кучу критических секций для этого - а смысл ? Надо убеждаться, что никто не пишет, в тот момент, когда происходит чтение, и в тот момент, когда происходит запись. Так как писателей потенциально много, то механизм синхронизации здорово усложняется.
← →
It's not me (2009-03-11 16:10) [37]То есть, с одной стороны:
>т.к. строка не станет инвалидной - у них там все продумано в этом плане
а с другой стороны твое:
>FOpenDev может не существовать или быть в другом месте
что на мой взгляд можно перевести как: "FOpenDev может стать инвалидной строкой".
← →
KSergey © (2009-03-11 16:27) [38]> Игорь Шевченко © (11.03.09 16:09) [36]
я понял.
Правда тут затронута интереснейшая для меня тема читателей-писателей, и, как я понял, схемы их раздельно (но взаимосвязанной) блокировки, но я как-нибудь создам по этому поводу отдельную тему, т.к. она мне жуть как интересна с некоторых пор :)
Ну а здесь в простейшем случае можно на все про все одну крит. секцию завести, и если не предполагается слишком интенсивного обращения - то вполне себе хорошее решение получится. (Если слишком интенсивно - тогад все потоки будут тупо стоять в очереди на этой крит. секции, это уже фигня получается, а не многопоточность)
← →
Игорь Шевченко © (2009-03-11 16:33) [39]KSergey © (11.03.09 16:27) [38]
В данном случае (в рамках моего понимания задачи, когда куча потоков открывает кучу устройств и список открытых устройств надо где-то иметь, а возможно, показывать) я бы использовал список TThreadList, и, соответственно, при открытии добавлял бы туда, при закрытии удалял, а при чтении, соответственно, читал бы, с блокировкой.
← →
oxffff © (2009-03-11 16:35) [40]
> It"s not me (11.03.09 16:07) [35]
>
> > Поясни, как можно сделать такой вывод?
>
>
> я пояснил вообще-то. Давай еще раз:
>
> Ты в посте [13] описал ситуацию, которая должна на мой взгляд
> привести к AV. (а что еще будет, если по твоим словам строчка
> может находиться уже в другом месте, чем думает один из
> потоков, в таком случае AV очень вероятен).
А почему ты думаешь, что она приведет к AV?
Обращение по недействительному указателю может вызвать AV, а может и не вызвать. AV является реакцией ОС на исключения процессора, которые происходят при определенных условиях.
Например обращение к отсутствующей странице, выход за сегмент описываемый дескриптором.
В твоих словах есть сомнение должно быть или не должно быть AV.
Так ты уж определись кто ты -
It"s not me (11.03.09 16:07) [35] или It"s not me (11.03.09 15:28) [31].
Как тебе такой поворот событий?
← →
clickmaker © (2009-03-11 17:09) [41]TMultiReadExclusiveWriteSynchronizer тут не поможет?
← →
Игорь Шевченко © (2009-03-11 17:15) [42]clickmaker © (11.03.09 17:09) [41]
TMultiWriteExclusiveReadSynchronizer - но его нету
← →
KSergey © (2009-03-11 17:48) [43]> clickmaker © (11.03.09 17:09) [41]
> TMultiReadExclusiveWriteSynchronizer
Научи?
← →
It's not me (2009-03-11 17:59) [44]
> Обращение по недействительному указателю может вызвать AV,
> а может и не вызвать
главное тут для меня, что МОЖЕТ вызывать AV. То, что описал ТЫ в результате МОЖЕТ выдать AV. А Тимохов однозначно сказал, что AV не может быть, ибо там как-то хитро string устроен. Вот и все.
Да и чего ты меня пытаешь ) Если ты уверен, что так писать неправильно - так и скажи, я ошибочно значит подумал )
> TMultiReadExclusiveWriteSynchronizer тут не поможет?
интересный класс, спасибо, я не знал о таком! Да, поможет несомненно, как аналог использования TCriticalSection. Осталось подразобраться в чем его преимущество, разбираюсь... Навскидку по коду (и названию класса :) ) понял то, что он позволяет сразу многим читать, но запись при этом эксклюзивна.
← →
clickmaker © (2009-03-11 18:05) [45]> [43] KSergey © (11.03.09 17:48)
> > clickmaker © (11.03.09 17:09) [41]
> > TMultiReadExclusiveWriteSynchronizer
>
> Научи?
> [цитата]
щас It"s not me разберется - научит -)
← →
It's not me (2009-03-11 18:10) [46]а че там разбираться )
Аналог TCriticalSection, но сделанный на мьютексе, а не критич. секции (что только лучше), только с разделениями на Read операции и Write.
Read операций сколько угодно, но только при отсутствии Write. Write эксклюзивна и делается при отутствии как read операций, так и других write, что логично.
Мне вообще кажется это скоро станет элементом языка. например, поля класса удобно было бы автоматически оборачивать в такие консструкции.
Грубо говоря все геттеры работают через read операции, все сеттеры через write.
← →
Eraser © (2009-03-11 19:22) [47]> но сделанный на мьютексе, а не критич. секции (что только
> лучше)
чем лучше? в курсе что такое критическая секция и зачем она вообще изобретена?
← →
DVM © (2009-03-11 19:37) [48]
> Аналог TCriticalSection, но сделанный на мьютексе, а не
> критич. секции (что только лучше), только с разделениями
> на Read операции и Write.
> Мне вообще кажется это скоро станет элементом языка.
Только это в 1000 раз медленнее крит секции будет.
← →
Городской Шаман (2009-03-11 19:39) [49]
> It"s not me (11.03.09 11:55) [10]
>
>
> > так даже с Integer-ом делать нельзя
>
> с integer"ом нельзя, я знаю. Но почему отсюда следует, что
> так нельзя делать с AnsiString - не понимаю.
В автобус входят два чукчи. Пеpвый спpашивает у водителя:
- Я доеду на этом автобусе до вокзала?
- Доедете. - спокойно отвечает водитель.
- А я? - спpашивает втоpой.
- И вы доедете. - так же спокойно отвечает водитель.
- А вот и не угадал! - pадуется втоpой. - Я pаньше сойду!
← →
Anatoly Podgoretsky © (2009-03-11 19:54) [50]> It"s not me (10.03.2009 19:10:00) [0]
> А плодить крит. секцию для работы с одной строчкой лениво.
Ленивым не место в программирование.
← →
Sapersky (2009-03-11 20:45) [51]Только это в 1000 раз медленнее крит секции будет.
Насколько я смог разглядеть - логика похожа на крит. секцию, сначала пытается обойтись Interlocked-функциями, если уж совсем никак - используются Events и WaitFor-функции. Так что должно быть как минимум не хуже КС.
Мьютексов там вообще нет.
← →
Сергей М. © (2009-03-11 20:59) [52]
> It"s not me (11.03.09 18:10) [46]
> на мьютексе
> элементом языка
Ты не понимаешь, какую ахинею ты сейчас несешь.
← →
oxffff © (2009-03-11 21:53) [53]
> Да и чего ты меня пытаешь ) Если ты уверен, что так писать
> неправильно - так и скажи, я ошибочно значит подумал )
Клиент должен сам дойти до кондиции.
← →
It's not me (2009-03-11 22:22) [54]Eraser © (11.03.09 19:22) [47]
чем лучше?
тем, что у мьютекса (на самом деле там event я спьяну не разглядел да один фиг) нормальный и правильный на мой взгляд режим работы - FIFO.
Eraser © (11.03.09 19:22) [47]
в курсе что такое критическая секция и зачем она вообще изобретена?
такие бесценные знания такому бездарю как я не могут быть доступны по определению )
DVM © (11.03.09 19:37) [48]
Только это в 1000 раз медленнее крит секции будет.
не может быть
Sapersky (11.03.09 20:45) [51]
Насколько я смог разглядеть - логика похожа на крит. секцию, сначала пытается обойтись Interlocked-функциями, если уж совсем никак - используются Events и WaitFor-функции. Так что должно быть как минимум не хуже КС
вот именно. А точнее, гораздо лучше дельфовой TCriticalSection, которая не использует полезные фичи секций, которые появились только в w2k+
Sapersky (11.03.09 20:45) [51]
Мьютексов там вообще нет.
да, там event...
Сергей М. © (11.03.09 20:59) [52]
Ты не понимаешь, какую ахинею ты сейчас несешь.
ну так отлично! Если я не понимаю, значит это не ахинея для меня. А значит все в пределах разумного.
← →
oxffff © (2009-03-11 22:40) [55]
> It"s not me (11.03.09 22:22) [54]
Умение смеятся на собой ценное качество. Я бы сказал самое ценное.
Уважаю.
← →
oxffff © (2009-03-11 22:41) [56]
> смеятся
смеяться
← →
It's not me (2009-03-12 01:03) [57]oxffff © (11.03.09 22:40) [55]
а ты первый на моем веку человек, который по делу и с глубокими знаниями уделал ИШ"а по начальному вопросу, в котором ИШ был полностью уверен )))
Уважаю.
За знания (хотел бы я через пару лет разбираться в программинге как ты) и за умение спорить ради истины, а не ради моральной победы над оппонентом (как большинство).
← →
It's not me (2009-03-12 01:04) [58]Ждем шутников на алкогольные темы ))
← →
Тын-Дын © (2009-03-12 01:21) [59]
> It"s not me (11.03.09 11:55) [10]
> > так даже с Integer-ом делать нельзяс integer"ом нельзя,
> я знаю. Но почему отсюда следует, что так нельзя делать
> с AnsiString - не понимаю.
Если ответишь на вопрос, почему нельзя с integer, то и на вопрос по поводу AnsiString вообще не возникнет.
← →
DVM © (2009-03-12 01:27) [60]
> It"s not me (11.03.09 22:22) [54]
> не может быть
Может, сравни производительность крит секции и например, мьютекса или семафора
← →
DVM © (2009-03-12 01:28) [61]
> Sapersky (11.03.09 20:45) [51]
> Насколько я смог разглядеть - логика похожа на крит. секцию,
> сначала пытается обойтись Interlocked-функциями, если уж
> совсем никак - используются Events и WaitFor-функции. Так
> что должно быть как минимум не хуже КС.
> Мьютексов там вообще нет.
А вона оно как. Тогда возможно и не медленнее так сильно.
← →
Eraser © (2009-03-12 03:39) [62]> [54] It"s not me (11.03.09 22:22)
> тем, что у мьютекса (на самом деле там event я спьяну не
> разглядел да один фиг) нормальный и правильный на мой взгляд
> режим работы - FIFO.
ну да, а в MS лохи систему пишут.
а на вопрос так и не ответи, чем критическая секция лучше мьютекса?
> А точнее, гораздо лучше дельфовой TCriticalSection, которая
> не использует полезные фичи секций, которые появились только
> в w2k+
делфивская TCriticalSection это не более, чем обертка над API функциями.
> [57] It"s not me (12.03.09 01:03)
> который по делу и с глубокими знаниями уделал ИШ"а
мда.. кто зачем сюда ходит, а It"s not me, чтобы уделать ИШа, ппц )
← →
Eraser © (2009-03-12 03:40) [63]> чем критическая секция лучше мьютекса?
или хуже, так яснее.
← →
It's not me (2009-03-12 12:38) [64]
> Если ответишь на вопрос, почему нельзя с integer, то и на
> вопрос по поводу AnsiString вообще не возникнет.
какой ты прямолинейный. Видимо, потому, что AnsiString это типа еще сложнее, чем integer.
А может ты тогда ответишь на вопрос, почему нельзя с integer (такой ведь простой тип), а с TThreadList можно (куда сложнее).
> Может, сравни производительность крит секции и например,
> мьютекса или семафора
так тебе надо - ты и сравнивай. Ты что, правда думаешь, что крит. секция это нечто особенное? Это такой же объект ядра, более того при возникновении блокировки для КРИТИЧЕСКОЙ СЕКЦИИ создается так любимый тобой МЬЮТЕКС (по крайней мере до висты, в висте они че то перемудрили с секциями) и в таком случае критическая секция сработает даже МЕДЛЕННЕЕ, чем МЬЮТЕКС впрямую. Так что перестань нести всякое разное.
Что касается производительности, у меня миллион event"ов (еще раз - МИЛЛИОН) создается несколько десятков миллисекунд. Вопрос производительности при блокировке только в том, что для засыпания потоку нужно уйти в режим ядра, а это относительно дорого. И критические секции в win2k специально немного модернизировали, добавив циклы перепроверки вхождения. Но дельфовый TCriticalSection это абсолютно не использует
> а на вопрос так и не ответи, чем критическая секция лучше
> мьютекса?
я тебе ответил. А если ты еще раз загонишься и ЕЩЕ РАЗ будешь мне доказывать, что я тебе не ответил - я тебе и на это не отвечу, запарил ты уже )
> делфивская TCriticalSection это не более, чем обертка над
> API функциями.
не может быть!!! Я всегда думал, что в TCS реализовано альтернативное ядро виндоус... Блииннн, я ламо просто! Как известно LMD, я пошел
← →
It's not me (2009-03-12 12:41) [65]
> более того при возникновении блокировки для КРИТИЧЕСКОЙ
> СЕКЦИИ создается так любимый тобой МЬЮТЕКС
или семафор. Я точно уже не помню, но это и не принципиально.
← →
clickmaker © (2009-03-12 13:05) [66]> procedure TMy.AddOpenDev(NewDev: string);
> begin
> FOpenDev := FOpenDev + NewDev + "|" ;
> end;
боюсь показаться дебилом, но я так и понял, что мешает написать
procedure TMy.AddOpenDev(NewDev: string);
begin
FCritSect.Enter;
try
FOpenDev := FOpenDev + NewDev + "|" ;
finally
FCritSect.Leave;
end;
end;
при чтении - то же самое. FCritSect - это, разумеется, глобальный объект
← →
It's not me (2009-03-12 14:10) [67]а что мешает делать так?
var
tl: TThreadList;
.......
var
List: TList;
begin
FCritSect.Enter;
try
List := tl.LockList;
try
РАБОТАЕМ!
finally
tl.UnlockList;
end;
FOpenDev := FOpenDev + NewDev + "|" ;
finally
FCritSect.Leave;
end;
end;
FCritSect - это, разумеется, глобальный объект
← →
DVM © (2009-03-12 15:12) [68]
> It"s not me (12.03.09 12:38) [64]
> так тебе надо - ты и сравнивай. Ты что, правда думаешь,
> что крит. секция это нечто особенное? Это такой же объект
> ядра, более того при возникновении блокировки для КРИТИЧЕСКОЙ
> СЕКЦИИ создается так любимый тобой МЬЮТЕКС (по крайней мере
> до висты, в висте они че то перемудрили с секциями) и в
> таком случае критическая секция сработает даже МЕДЛЕННЕЕ,
> чем МЬЮТЕКС впрямую
Охренеть просто, прямо глаза открыл мне. Мьютекс, имеющий большую функциональность, чем критическая секция и более сложную реализацию, оказывается работает быстрее, чем более простая критическая секция.
Процедура входа и выхода критических секций обычно занимает меньшее время, нежели аналогичные операции мьютекса.
← →
DVM © (2009-03-12 15:20) [69]
> Ты что, правда думаешь, что крит. секция это нечто особенное?
> Это такой же объект ядра
Критическая секция НЕ ОБЪЕКТ ЯДРА! Не придумывай. Она внутри себя содержит объект ядра и то вроде не всегда.
← →
Тын-Дын © (2009-03-12 15:28) [70]
> It"s not me (12.03.09 12:38) [64]
> > Если ответишь на вопрос, почему нельзя с integer, то и
> на > вопрос по поводу AnsiString вообще не возникнет.какой
> ты прямолинейный. Видимо, потому, что AnsiString это типа
> еще сложнее, чем integer.А может ты тогда ответишь на вопрос,
> почему нельзя с integer (такой ведь простой тип), а с TThreadList
> можно (куда сложнее).
Я не собираюсь тебе разжёвывать тривиальные вещи. Возьми Рихтера и прочитай (там всего пару страниц достаточно) про работу с целыми числами из разных потоков.
Достаточно понять только одну вещь - для безопасной многопоточной работы с данными операция должна быть атомарной с точки зрения изменения данных.
Этого достаточно.
> так тебе надо - ты и сравнивай. Ты что, правда думаешь,
> что крит. секция это нечто особенное? Это такой же объект
> ядра, более того при возникновении блокировки для КРИТИЧЕСКОЙ
> СЕКЦИИ создается так любимый тобой МЬЮТЕКС (по крайней мере
> до висты, в висте они че то перемудрили с секциями) и в
> таком случае критическая секция сработает даже МЕДЛЕННЕЕ,
> чем МЬЮТЕКС впрямую. Так что перестань нести всякое разное.
>
Вот блин изобретатель хренов!
Критическая секция - самый быстрый объект для синхронизации.
← →
Тын-Дын © (2009-03-12 15:29) [71]PS.
Не считая спин-блокировку, конечно.
← →
It's not me (2009-03-12 15:35) [72]
> Процедура входа и выхода критических секций обычно занимает
> меньшее время
вот видишь. Ты и сам это понимаешь. Пишешь слово - обычно.
Обычно - это когда? Когда нет блокировки? Или когда есть? И что в твоей программе обычно, то в другой программе необычно.
Поэтому писать, что мьютекс в ТЫСЯЧИ РАЗ медленнее крит. секций - наглая ложь.
> Мьютекс, имеющий большую функциональность, чем критическая
> секция и более сложную реализацию, оказывается работает
> быстрее, чем более простая критическая секция
в некоторых случаях да. А как вообще может быть иначе, если в некоторых ситуациях вход в критическую секцию приводит к созданию мьютекста и синхронизации на нем? Как в данном случае может работать быстрее (будем говорить про тысячу раз?), чем прямое использование мьютекса?
← →
Eraser © (2009-03-12 15:39) [73]> [64] It"s not me (12.03.09 12:38)
> так тебе надо - ты и сравнивай. Ты что, правда думаешь,
> что крит. секция это нечто особенное? Это такой же объект
> ядра, более того при возникновении блокировки для КРИТИЧЕСКОЙ
> СЕКЦИИ создается так любимый тобой МЬЮТЕКС (по крайней мере
> до висты, в висте они че то перемудрили с секциями) и в
> таком случае критическая секция сработает даже МЕДЛЕННЕЕ,
> чем МЬЮТЕКС впрямую. Так что перестань нести всякое разное.
>
> Что касается производительности, у меня миллион event"ов
> (еще раз - МИЛЛИОН) создается несколько десятков миллисекунд.
> Вопрос производительности при блокировке только в том, что
> для засыпания потоку нужно уйти в режим ядра, а это относительно
> дорого. И критические секции в win2k специально немного
> модернизировали, добавив циклы перепроверки вхождения. Но
> дельфовый TCriticalSection это абсолютно не использует
у тебя ошибочное представление о работе критических секций, читай дядю Рихтера и Руссиновича.
так кстати и не понял, чем тебе TCriticalSection не угодил и почему там что-то не используется? там вызов API-функции.
← →
It's not me (2009-03-12 15:41) [74]
> Я не собираюсь тебе разжёвывать тривиальные вещи
зато ты уверен, что я их не знаю ))))
> Возьми Рихтера и прочитай
мне кажется это скоро станем универсальным наездом на всех и вся )
не катит уже с прошлого века, Рихтера уж кто только не читал. Сейчас моднее на руссиновича ссылаться.
> для безопасной многопоточной работы с данными операция должна
> быть атомарной с точки зрения
ух ты. А что же тогда работа с TThreadList при всей своей абсолютной неатомарности при этом полностью безопасна для многопоточной работы? )))
> Критическая секция - самый быстрый объект для синхронизации
а как же interloc...
> Не считая спин-блокировку, конечно
ах, как жаль не успел )))
← →
DVM © (2009-03-12 15:43) [75]
> It"s not me (12.03.09 15:35) [72]
> Поэтому писать, что мьютекс в ТЫСЯЧИ РАЗ медленнее крит.
> секций - наглая ложь.
я писал не про мьютекс. А про TMultiReadExclusiveWriteSynchronizer, который мало того глючный до безобразия в некоторых версия Delphi, но еще и тормозной.
Не в 1000 раз (понятно, что это было преувеличение), но в разы и даже десятки раз.
← →
Сергей М. © (2009-03-12 15:56) [76]
> It"s not me (12.03.09 15:41) [74]
> что же тогда работа с TThreadList при всей своей абсолютной
> неатомарности при этом полностью безопасна для многопоточной
> работы
Ты с головой вообще дружишь когда-нибудь ?
TThreadList использует ту же самую крит.секцию, которую тебе "лениво плодить".
Вот именно потому что операции со объектом-списком TList не являются атомарными, TThreadList и использует объект синхронизации.
← →
It's not me (2009-03-12 16:09) [77]
> у тебя ошибочное представление о работе критических секций,
> читай дядю Рихтера
перечитал в электроном виде. Да, действительно, там не мьютекс или семафор создается, а event. Совсем что-то с памятью... Впрочем, не вижу принципиальной разницы.
> и Руссиновича
DVM, во, видишь! Грамотные наезжальщики оперируют фамилиями Руссинович. Рихтер не в моде ужо.
> А про TMultiReadExclusiveWriteSynchronizer, который мало
> того глючный до безобразия в некоторых версия Delphi
пример, в каком месте он глючный?
Ах да, ты уже наверное не помнишь и лезть в старые дельфи влом, короче бла бла бла
> но еще и тормозной
пример места, где он тормозной?
> так кстати и не понял, чем тебе TCriticalSection не угодил
> и почему там что-то не используется?
не используется новая функция появившееся в w2k+, не просто initializecriticalsection (или как там), а ...AndSpinCount
← →
It's not me (2009-03-12 16:16) [78]
> Ты с головой вообще дружишь когда-нибудь ?
не дружу.
А ты что, дружишь со своей головой? И как, успешно? Вы, наверное, друг к другу в гости ходите, чаи гоняете, здороваетесь при встрече?
> Вот именно потому что операции со объектом-списком TList
> не являются атомарными, TThreadList и использует объект
> синхронизации
а-а-а... Так вот ты куда пропал, Капитан Очевидность!!! )))))))))))))
← →
Тын-Дын © (2009-03-12 16:16) [79]
> It"s not me (12.03.09 15:41) [74]
> > Я не собираюсь тебе разжёвывать тривиальные вещизато ты
> уверен, что я их не знаю ))))
По твоим высказываниям как раз это и следует.
> мне кажется это скоро станем универсальным наездом на всех
> и вся )не катит уже с прошлого века, Рихтера уж кто только
> не читал. Сейчас моднее на руссиновича ссылаться.
Это не наезд, а именно совет ознакомиться с темой, которой ты не владеешь, из первоисточника (можно так сказать).
Ну если тебе моднее на Руссиновича, то почитай Руссиновича для на чала.
> ух ты. А что же тогда работа с TThreadList при всей своей
> абсолютной неатомарности при этом полностью безопасна для
> многопоточной работы? )))
Вах! Какой бред!
Лишний раз подтверждаешь ПОЛНОЕ незнание темы.
А раз не знаешь, то слушай, что тебе говорят, а не огрызайся не по делу.
> > Критическая секция - самый быстрый объект для синхронизацииа
> как же interloc...
Функии Interlocked... имеют сликом узкую область применения, чтобы говорить о них как объектах синхронизации (тем более, что они и не являются таковыми).
← →
Eraser © (2009-03-12 16:16) [80]> [77] It"s not me (12.03.09 16:09)
> DVM, во, видишь! Грамотные наезжальщики оперируют фамилиями
> Руссинович. Рихтер не в моде ужо.
если ты это про меня, то первым был упомянут дядя Рихтер )
> не используется новая функция появившееся в w2k+, не просто
> initializecriticalsection (или как там), а ...AndSpinCount
странный довод. эта функциональность не нужна, где попало.
> пример места, где он тормозной?
набросай простенький тест и посмотри.
← →
Тын-Дын © (2009-03-12 16:18) [81]Вобщем видно, что автор, претендуя на знание предметной области, раздувает пустой флейм, походя поливая всех по поводу своего флуда.
← →
Тын-Дын © (2009-03-12 16:20) [82]
> не используется новая функция появившееся в w2k+, не просто
> initializecriticalsection (или как там), а ...AndSpinCount
А тебе она зачем - эта функция? Для чего?
Чтобы пофлудить просто?
Для тебя конкретно где ты видишь область её применения, в каких задачах?
← →
It's not me (2009-03-12 16:24) [83]
> По твоим высказываниям как раз это и следует.
как всегда забыл кое-что дописать.
> Это не наезд, а именно совет ознакомиться с темой
это не совет, это попытка пропонтоваться на пустом месте, абсолютно не въезжаю в нить беседы.
> Вах! Какой бред!
> Лишний раз подтверждаешь ПОЛНОЕ незнание темы
Вах! лишний раз подтверждаешь ПОЛНОЕ отсутствие ЧЮ
> если ты это про меня, то первым был упомянут дядя Рихтер
> )
и за это тебе несомненно незачот!
> набросай простенький тест и посмотри.
зачем. Ты ведь утверждаешь, что он ТОРМОЗНОЙ.
Так прокодируй сюда это место, где будут возникать тормоза, раскажи как бы ты намного лучше и быстрее бы сделал это место.
← →
It's not me (2009-03-12 16:27) [84]
> Для тебя конкретно где ты видишь область её применения,
> в каких задачах?
в таких же, в каких видят ее все адекватные программисты, вроде дядьки рихтера и руссиновича. Когда среднее время работы с разделяемым ресурсом меньше, чем совокупное среднее время входа и выхода нити из режима ядра.
← →
Тын-Дын © (2009-03-12 16:38) [85]
> это не совет, это попытка пропонтоваться на пустом месте,
> абсолютно не въезжаю в нить беседы.
Ты бы нить сам в руках хоть держал.
Выкрики из толпы без аргументов и всё.
Для понимания элементарщины иди в конференцию "Начинающие" - там может и разъяснят более подробно такие вещи как работа со строками и целыми числами из разных потоков.
← →
Тын-Дын © (2009-03-12 16:39) [86]
> Когда среднее время работы с разделяемым ресурсом меньше,
> чем совокупное среднее время входа и выхода нити из режима
> ядра.
Интересно, а ты знаешь, что нити не обязательно переходить в режим ядра для синхронизации?
← →
DVM © (2009-03-12 16:39) [87]
> It"s not me (12.03.09 16:09) [77]
> DVM, во, видишь! Грамотные наезжальщики оперируют фамилиями
> Руссинович. Рихтер не в моде ужо.
А я то тут причем? Я не Рихтера, ни Руссиновича, ни даже Фленова не упоминал.
> пример, в каком месте он глючный?
>
> Ах да, ты уже наверное не помнишь и лезть в старые дельфи
> влом, короче бла бла бла
Это ты не помнишь, а я как раз помню. В версиях Delphi ниже 7 иногда приводил к взаимоблокировке потоков. Про 7 не знаю, после D6 перестал пользоваться TMREWS из за глюков.
> пример места, где он тормозной?
В реализации. TMREWS проектировался для очень узкого круга применений и так до ума был не доведен из-за узости применения и редкости использования.
Производительность его ВНЕ области его применения крайне низка. Уж по крайней мере гораздо ниже крит. секций. Выигрыш с его помощью перед крит секциями получить можно, но редко. Мне такая задача попадалась всего раз.
Не веришь - возьми сравни. Я уже сравнивал в свое время, лично для убеждения тебя никаких сравнений проводить не буду.
← →
Тын-Дын © (2009-03-12 16:39) [88]У тебя почему-то везде звучит про эти переходы?
← →
Palladin © (2009-03-12 16:42) [89]
> DVM © (12.03.09 16:39) [87]
Хем. А можно пример ситуации когда TMREWS приводит к дидлоку?
← →
Сергей М. © (2009-03-12 16:48) [90]
> It"s not me (12.03.09 16:16) [78]
> Очевидность
Что ж ты тогда лепишь горбатого про "лениво", в то время как в [67] сам двигаешь оглобли в сторону крит.секций ?
← →
DVM © (2009-03-12 16:59) [91]
> Palladin © (12.03.09 16:42) [89]
Я немного перепутал, в версиях Delphi ниже 6 дедлок наблюдается.
А пример ситуации - надо подумать. Я уж забыл в чем проблема была. Помню, что надо было править SysUtils.pas, на сайте борланда даже что-то в виде патча лежало. А висло все когда очень много потоков пыталось получить доступ к TMREWS.
← →
DVM © (2009-03-12 17:03) [92]
> на сайте борланда даже что-то в виде патча лежало
вот оно вроде http://cc.embarcadero.com/Item/17761
Хотя не вроде в D6 тоже видать глюк остался, раз это патч для D6.
← →
It's not me (2009-03-12 17:05) [93]
> Хем. А можно пример ситуации когда TMREWS приводит к дидлоку?
тоже интересно
> TMREWS проектировался для очень узкого круга применений
какая разница для чего он проектировался. Ты можешь в его КОДЕ показать место, которое написано неоптимально, где можно написать лучше и так далее?
> лично для убеждения тебя никаких сравнений проводить не
> буду
да и не надо. Фигли тогда об этом говорить вообще )
> нити не обязательно переходить в режим ядра для синхронизации?
смотря что называть синхронизацией.
Для засыпания (suspend), чтобы чего-то ждать без траты процессорного времени - обязательно.
> в то время как в [67] сам
в [67] любому очевидно приведен стёбный, избыточный код
← →
It's not me (2009-03-12 17:07) [94]гы, в [67] откуда-то вкрался FOpenDev, чудеса ) Вот так было запланировано:
а что мешает делать так?var
tl: TThreadList;
.......
var
List: TList;
begin
FCritSect.Enter;
try
List := tl.LockList;
try
РАБОТАЕМ!
finally
tl.UnlockList;
end;
finally
FCritSect.Leave;
end;
end;
← →
Palladin © (2009-03-12 17:09) [95]
> DVM © (12.03.09 17:03) [92]
От спасибо. А то я тут как раз синхронизацию потока с ReadDirectoryChangesW на них замутил, но еще не запустил в эскплуатацию... щаз бы сидел волосы рвал на экзотических местах )
← →
DVM © (2009-03-12 17:09) [96]
> It"s not me (12.03.09 17:05) [93]
> какая разница для чего он проектировался.
Разница есть. Использовать класс надо по назначению, если желаешь получить хоть какой-то выигрыш от его использования. Иначе получишь только проблемы.
> Ты можешь в его КОДЕ показать место, которое написано неоптимально
Какая разница какое место написано неоптимально? Есть факт - использование TMREWS замедляет работу программы, и этот факт легко проверить экспериментально. Если не веришь и не хочешь проверить - ради бога оставайся при своем, мне то что до того. что твой код будет работать медленне, а если ниже D7 так еще и с глюками.
← →
Сергей М. © (2009-03-12 17:19) [97]
> в [67] любому очевидно приведен стёбный, избыточный код
Так вот, г-н агрессивный, если ты занялся "стёбом", то и будь готов что и сам будешь "отстебан" по полной программе).. А как же иначе ?
Собссно, как ты должно быть понимаешь, стебут тебя здесь уже давно и от души - напросился же ! - и тебе это, видимо, доставляет наслаждение.
← →
It's not me (2009-03-12 17:19) [98]
> Использовать класс надо по назначению
с чего это ты взял. Если женские колготки отлично подходят для хранения лука - почему бы их так не использовать?
Ни на одной упаковке женских колготок никогда не читал, что их можно использовать для хранения и сушки лука.
А некоторые вообще делают дырки в пластиковых бутылках аква минерале и используют бутылки черте знает как.
> Какая разница какое место написано неоптимально?
принципиальная. Это позволяет проанализировать правду ты говоришь или нет.
Ты же утверждаешь, что TMREWS работает медленно. Я подумал почему-то, что ты знаешь почему именно медленно он работает, ибо на первый взгляд он ничем не хуже, а при множественном чтении так и гораздо лучше TCriticalSection. Но как оказалось ты не знаешь.
Ты просто когда-то делал какие-то тесты. Я тоже сейчас могу тест сделать, где будет 100 читающих потоков и 1 пишущий. И я уверен на 99%, что TMREWS будет работать быстрее TCriticalSection. Я тебе об этом сообщу, ты попросишь код теста, я тебе приведу код, ты скажешь - у тебя тест неправильный. Ну и нахрен мне это нужно.
← →
DVM © (2009-03-12 17:31) [99]
> где будет 100 читающих потоков и 1 пишущий. И я уверен на
> 99%, что TMREWS будет работать быстрее TCriticalSection
Будет быстрее, тут даже проверять нечего. Это как раз тот случай, когда применение его оправдано. Если конечно не зависнет при таком то количестве потоков.
> Это позволяет проанализировать правду ты говоришь или нет.
Да вру я конечно, чтобы тебя преубедить. Мне делать больше нечего.
> Я подумал почему-то, что ты знаешь почему именно медленно
> он работает, ибо на первый взгляд он ничем не хуже, а при
> множественном чтении так и гораздо лучше TCriticalSection.
>
Я не знаю, не копался во внутренностях. Просто использовал. И замерял время. Нашел что работает неоптимально. При множественном чтении вообще в нем нет смысла, если нет записи, как впрочем и в крит. секциях, если есть более одного писателя, то тоже в нем нет смысла, крит секции будут работать быстрее.
← →
Palladin © (2009-03-12 17:41) [100]
> если есть более одного писателя, то тоже в нем нет смысла,
> крит секции будут работать быстрее.
Не совсем так. Дело не в соотнешнии количества читателей к количеству писателей, дело в соотношений частоты чтения к частоте записи.
← →
Palladin © (2009-03-12 17:45) [101]чет я сморозил совсем не то, что сказать хотел... )
← →
It's not me (2009-03-12 17:59) [102]
> Я не знаю, не копался во внутренностях
понятно.
← →
DVM © (2009-03-12 18:01) [103]
> Palladin © (12.03.09 17:41) [100]
> Дело не в соотнешнии количества читателей к количеству писателей,
> дело в соотношений частоты чтения к частоте записи.
А это не одно и то же? :)
← →
Palladin © (2009-03-12 18:05) [104]
> DVM © (12.03.09 18:01) [103]
одно и тоже :)
я термин "количество" просто слишком буквально воспринял не добавил в уме "одновременно читающих/пишущих" :)
← →
Leonid Troyanovsky © (2009-03-12 20:17) [105]
> DVM © (12.03.09 16:59) [91]
> Я немного перепутал, в версиях Delphi ниже 6 дедлок наблюдается.
У него был еще один недостаток был (а может и остался, не проверял).
Множество читателей не давали работать писателю.
Хотя, у SWMRG object by D.Richter (WFP 2 ed.) был тот же деффект.
Ну, а если уж вспомнили Джефа, то нельзя пройти мимо одной
из моих любимых ссылок:
http://msdn.microsoft.com/en-us/magazine/cc302329.aspx
Многие "легкие мьютексы" в win32 пошли, IMHO, с тех времен.
--
Regards, LVT.
← →
Игорь Шевченко © (2009-03-12 20:22) [106]"Один дурак может задать вопрос, на который и сто мудрецов не ответят" (с) фольклор
Страницы: 1 2 3 вся ветка
Форум: "Прочее";
Текущий архив: 2009.05.17;
Скачать: [xml.tar.bz2];
Память: 0.8 MB
Время: 0.007 c