Информация об изменениях

Сообщение Re[4]: Реентерабельность и STL от 25.04.2018 20:24

Изменено 25.04.2018 20:47 _hum_

Re[4]: Реентерабельность и STL
Здравствуйте, watchmaker, Вы писали:

W>Здравствуйте, _hum_, Вы писали:


__>>>> цикл наподобие будет корректно работать

W>>>Да, такой цикл будет корректно работать.
__>>почему?
W>Потому что сказано
W>

W>[container.requirements.dataraces]

W>1 For purposes of avoiding data races (20.5.5.9), implementations shall consider the following functions to be
W>const: begin, end, rbegin, rend, front, back, data, find, lower_bound, upper_bound, equal_range, at
W>and, except in associative or unordered associative containers, operator[].
W>2 Notwithstanding 20.5.5.9, implementations are required to avoid data races when the contents of the contained
W>object in different elements in the same container, excepting vector<bool>, are modified concurrently.

о. спасибо.

__>>потому что я ориентировался на следующее понимание реентерабельности:

__>>Так вот в таком понимании мне
W>Если будешь наделять более-менее устоявшийся термин каким-то новым "своим пониманием", то тебя скорее-всего просто не поймут. Не советую так делать.

Кхм.. дело в том, что не совсем понятно, что такое устоявшийся (есть какой-то аналог БСЭ для computer science?). Я открыл сперва русскую Вики. Там черным по белому написано, то, что я привел выше, и при этом еще и сказано

Реентерабельность тесно связана с безопасностью функции в многопоточной среде (thread-safety), тем не менее, это разные понятия (в практическом программировании под современные ОС термин «реентерабельный» на деле равносилен термину «thread-safe»).


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


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


а я нигде не утверждал, что они равносильны. Я лишь говорил, что мне достаточно было реентерабельности (в "моем понимании").

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

upd. Кстати, забавно. В ссылках в ангаязычной статье про реентерабельность:
Kerrisk 2010, p. 657.

Alghtought the use of critical sections to implement thread safety is a significiant improvement over the use of pre-function mutexes, it is still somewhat inefficient because there is a cost to locking and unlocking a mutex. A reinterant function achieves thread safety without the use of mutexes. It does this by avoiding the use of global and static variables. Any information that must be returned to the caller or maintained between calls to the fucntion, is stored in buffer allocated by caller


Chen, Raymond (June 29, 2004). "The Difference Between Thread-safety and Re-entrancy". The Old New Thing. Microsoft Developer Network. Archived from the original on April 24, 2018. Retrieved April 24, 2018.

An operation is "thread-safe" if it can be performed from multiple threads safely, even if the calls happen simultaneously on multiple threads.

An operation is re-entrant if it can be performed while the operation is already in progress (perhaps in another context). This is a stronger concept than thread-safety, because the second attempt to perform the operation can even come from within the same thread.

Это как бы противоречит написанному в англоязычной вики.
Re[4]: Реентерабельность и STL
Здравствуйте, watchmaker, Вы писали:

W>Здравствуйте, _hum_, Вы писали:


__>>>> цикл наподобие будет корректно работать

W>>>Да, такой цикл будет корректно работать.
__>>почему?
W>Потому что сказано
W>

W>[container.requirements.dataraces]

W>1 For purposes of avoiding data races (20.5.5.9), implementations shall consider the following functions to be
W>const: begin, end, rbegin, rend, front, back, data, find, lower_bound, upper_bound, equal_range, at
W>and, except in associative or unordered associative containers, operator[].
W>2 Notwithstanding 20.5.5.9, implementations are required to avoid data races when the contents of the contained
W>object in different elements in the same container, excepting vector<bool>, are modified concurrently.

о. спасибо.

__>>потому что я ориентировался на следующее понимание реентерабельности:

__>>Так вот в таком понимании мне
W>Если будешь наделять более-менее устоявшийся термин каким-то новым "своим пониманием", то тебя скорее-всего просто не поймут. Не советую так делать.

Кхм.. дело в том, что не совсем понятно, что такое устоявшийся (есть какой-то аналог БСЭ для computer science?). Я открыл сперва русскую Вики. Там черным по белому написано, то, что я привел выше, и при этом еще и сказано

Реентерабельность тесно связана с безопасностью функции в многопоточной среде (thread-safety), тем не менее, это разные понятия (в практическом программировании под современные ОС термин «реентерабельный» на деле равносилен термину «thread-safe»).


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


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


а я нигде не утверждал, что они равносильны. Я лишь говорил, что мне достаточно было реентерабельности (в "моем понимании").

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

upd. Кстати, забавно. В ссылках в ангаязычной статье про реентерабельность:
Kerrisk 2010, p. 657.

Alghtought the use of critical sections to implement thread safety is a significiant improvement over the use of pre-function mutexes, it is still somewhat inefficient because there is a cost to locking and unlocking a mutex. A reinterant function achieves thread safety without the use of mutexes. It does this by avoiding the use of global and static variables. Any information that must be returned to the caller or maintained between calls to the fucntion, is stored in buffer allocated by caller


Chen, Raymond (June 29, 2004). "The Difference Between Thread-safety and Re-entrancy". The Old New Thing. Microsoft Developer Network. Archived from the original on April 24, 2018. Retrieved April 24, 2018.

An operation is "thread-safe" if it can be performed from multiple threads safely, even if the calls happen simultaneously on multiple threads.

An operation is re-entrant if it can be performed while the operation is already in progress (perhaps in another context). This is a stronger concept than thread-safety, because the second attempt to perform the operation can even come from within the same thread.

Это как бы противоречит написанному в англоязычной вики (и соответствует написанному в русскоязычной ).