Сообщение Re[12]: Зачем нам асинхронность? от 18.08.2020 14:33
Изменено 18.08.2020 14:44 Serginio1
Re[12]: Зачем нам асинхронность?
Здравствуйте, ksandro, Вы писали:
K>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, ksandro, Вы писали:
K>>>Во многих случаях параллельное исполнение вообще не нужно, нажен просто неблокирующив ввод вывод, что вполне можно сделать без многопоточности. Это не очень просто, но все-таки не так опасно как работа с потоками.
S>>В большинстве параллельный код вообще не блокирует операции записи.
K>Это как? Если так, то операция записи сама по себе потококобезопасная, то есть использует блокировку где-то внутри. Ну или ты пишешь в разные места. Или я что-то недопонимаю, я все таки не .net разработчик
Операция записи как раз не потокобезопасна. Пример из БД. Тебе нужно модифицировать набор записей в котором присутствует касаа.
Ту не можешь одновременно списать деньги, так как их может оказаться меньше. Но транзакция может и не завершиться если по каким то причинам эти деньги спасить нельзя.
И вторая транзакция должна дождаться, пока первая не закомитится или не откатится.
Если ты используешь общие данные только на чтение, то и блокировки не нужныю
S>>Там где есть запись обычно работают блокировки ReadWriteLock
K>Ужасно тормозная вещь, имеет смысл, толко когда у очень тебя много параллельных чтений и очень мало записей.
Так так в большинстве и существует. Берем ту же БД и транзакции. Там в большинстве блокировки именно на чтение
S>>То есть о каком то замедлении вообще речи не идет. Записей значительно меньше чтения. И ради этого специально тормозить код для межпроцесного взаимодействия.
S>>Не слишком ли жирно?
S>> Есть куча потокобезопасных классов https://docs.microsoft.com/ru-ru/dotnet/api/system.collections.concurrent?view=netcore-3.1
K>Ага, вот сделаем, все коллекции потокобезопасными, а потом не понимаем, почему программа работает медленнее, чем однопоточная.
Прежде чем говорить, ты бы пример привел где эти тормоза. Вот взаимодействие между процессами там дикие тормоза получишь.
K>Я понимаю, что есть куча всяких штук для различной синхронизации. И их количество показывает, что синхронизация, вещь не простая. И они никак не могут меня защитить от случайного обращения к одной области памяти из разных потоков. Я должен их явно ставить.
Не синхронизация, а блокировки. Синхронизация это выполнение кода в одном потоке.
Но если ты используешь асинхронность тот же JavaScript работает на одном потоке, но доступ к данным из разных задач не защищен.
Ничего не надо ставить если используешь только чтение.
K>Но вообще рекомендую попробовать переписать твою прогу в один поток, почему-то мне кажется что у тебя все заработает в разы быстрее...
Угу проходили. У меня на некоторых вещах стоят семафоры, что бы контролировать количество одновременных запросов. Поверь ты не прав.
Многопоточность дает практический пропорциональный прирост количеству потоков (по количество ядер + учет хайпертридинга )
Просто они нужны, что бы давать отлуп иначе сервер не справляется аля DoS-атака.
Еще раз в большинстве случаев происходит чтение данных , в большинстве случаев к базе данных. Нет проблем с многопоточностью.
Твои проблемы надуманы.
K>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, ksandro, Вы писали:
K>>>Во многих случаях параллельное исполнение вообще не нужно, нажен просто неблокирующив ввод вывод, что вполне можно сделать без многопоточности. Это не очень просто, но все-таки не так опасно как работа с потоками.
S>>В большинстве параллельный код вообще не блокирует операции записи.
K>Это как? Если так, то операция записи сама по себе потококобезопасная, то есть использует блокировку где-то внутри. Ну или ты пишешь в разные места. Или я что-то недопонимаю, я все таки не .net разработчик
Операция записи как раз не потокобезопасна. Пример из БД. Тебе нужно модифицировать набор записей в котором присутствует касаа.
Ту не можешь одновременно списать деньги, так как их может оказаться меньше. Но транзакция может и не завершиться если по каким то причинам эти деньги спасить нельзя.
И вторая транзакция должна дождаться, пока первая не закомитится или не откатится.
Если ты используешь общие данные только на чтение, то и блокировки не нужныю
S>>Там где есть запись обычно работают блокировки ReadWriteLock
K>Ужасно тормозная вещь, имеет смысл, толко когда у очень тебя много параллельных чтений и очень мало записей.
Так так в большинстве и существует. Берем ту же БД и транзакции. Там в большинстве блокировки именно на чтение
S>>То есть о каком то замедлении вообще речи не идет. Записей значительно меньше чтения. И ради этого специально тормозить код для межпроцесного взаимодействия.
S>>Не слишком ли жирно?
S>> Есть куча потокобезопасных классов https://docs.microsoft.com/ru-ru/dotnet/api/system.collections.concurrent?view=netcore-3.1
K>Ага, вот сделаем, все коллекции потокобезопасными, а потом не понимаем, почему программа работает медленнее, чем однопоточная.
Прежде чем говорить, ты бы пример привел где эти тормоза. Вот взаимодействие между процессами там дикие тормоза получишь.
K>Я понимаю, что есть куча всяких штук для различной синхронизации. И их количество показывает, что синхронизация, вещь не простая. И они никак не могут меня защитить от случайного обращения к одной области памяти из разных потоков. Я должен их явно ставить.
Не синхронизация, а блокировки. Синхронизация это выполнение кода в одном потоке.
Но если ты используешь асинхронность тот же JavaScript работает на одном потоке, но доступ к данным из разных задач не защищен.
Ничего не надо ставить если используешь только чтение.
K>Но вообще рекомендую попробовать переписать твою прогу в один поток, почему-то мне кажется что у тебя все заработает в разы быстрее...
Угу проходили. У меня на некоторых вещах стоят семафоры, что бы контролировать количество одновременных запросов. Поверь ты не прав.
Многопоточность дает практический пропорциональный прирост количеству потоков (по количество ядер + учет хайпертридинга )
Просто они нужны, что бы давать отлуп иначе сервер не справляется аля DoS-атака.
Еще раз в большинстве случаев происходит чтение данных , в большинстве случаев к базе данных. Нет проблем с многопоточностью.
Твои проблемы надуманы.
Re[12]: Зачем нам асинхронность?
Здравствуйте, ksandro, Вы писали:
K>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, ksandro, Вы писали:
K>>>Во многих случаях параллельное исполнение вообще не нужно, нажен просто неблокирующив ввод вывод, что вполне можно сделать без многопоточности. Это не очень просто, но все-таки не так опасно как работа с потоками.
S>>В большинстве параллельный код вообще не блокирует операции записи.
K>Это как? Если так, то операция записи сама по себе потококобезопасная, то есть использует блокировку где-то внутри. Ну или ты пишешь в разные места. Или я что-то недопонимаю, я все таки не .net разработчик
Операция записи как раз не потокобезопасна. Пример из БД. Тебе нужно модифицировать набор записей в котором присутствует касаа.
Ту не можешь одновременно списать деньги, так как их может оказаться меньше. Но транзакция может и не завершиться если по каким то причинам эти деньги спасить нельзя.
И вторая транзакция должна дождаться, пока первая не закомитится или не откатится.
Если ты используешь общие данные только на чтение, то и блокировки не нужныю
S>>Там где есть запись обычно работают блокировки ReadWriteLock
K>Ужасно тормозная вещь, имеет смысл, толко когда у очень тебя много параллельных чтений и очень мало записей.
Так так в большинстве и существует. Берем ту же БД и транзакции. Там в большинстве блокировки именно на чтение
S>>То есть о каком то замедлении вообще речи не идет. Записей значительно меньше чтения. И ради этого специально тормозить код для межпроцесного взаимодействия.
S>>Не слишком ли жирно?
S>> Есть куча потокобезопасных классов https://docs.microsoft.com/ru-ru/dotnet/api/system.collections.concurrent?view=netcore-3.1
K>Ага, вот сделаем, все коллекции потокобезопасными, а потом не понимаем, почему программа работает медленнее, чем однопоточная.
Прежде чем говорить, ты бы пример привел где эти тормоза. Вот взаимодействие между процессами там дикие тормоза получишь.
K>Я понимаю, что есть куча всяких штук для различной синхронизации. И их количество показывает, что синхронизация, вещь не простая. И они никак не могут меня защитить от случайного обращения к одной области памяти из разных потоков. Я должен их явно ставить.
Не синхронизация, а блокировки. Синхронизация это выполнение кода в одном потоке.
Но если ты используешь асинхронность тот же JavaScript работает на одном потоке, но доступ к данным из разных задач не защищен.
Ничего не надо ставить если используешь только чтение.
K>Но вообще рекомендую попробовать переписать твою прогу в один поток, почему-то мне кажется что у тебя все заработает в разы быстрее...
Угу проходили. У меня на некоторых вещах стоят семафоры, что бы контролировать количество одновременных запросов. Поверь ты не прав.
Многопоточность дает практический пропорциональный прирост количеству потоков (по количество ядер + учет хайпертридинга и на самом деле больше так как внутри могут выполняться асинхронные запросы к диску, БД на другом компе итд)
Просто они нужны, что бы давать отлуп иначе сервер не справляется аля DoS-атака.
Еще раз в большинстве случаев происходит чтение данных , в большинстве случаев к базе данных. Нет проблем с многопоточностью.
Твои проблемы надуманы.
K>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, ksandro, Вы писали:
K>>>Во многих случаях параллельное исполнение вообще не нужно, нажен просто неблокирующив ввод вывод, что вполне можно сделать без многопоточности. Это не очень просто, но все-таки не так опасно как работа с потоками.
S>>В большинстве параллельный код вообще не блокирует операции записи.
K>Это как? Если так, то операция записи сама по себе потококобезопасная, то есть использует блокировку где-то внутри. Ну или ты пишешь в разные места. Или я что-то недопонимаю, я все таки не .net разработчик
Операция записи как раз не потокобезопасна. Пример из БД. Тебе нужно модифицировать набор записей в котором присутствует касаа.
Ту не можешь одновременно списать деньги, так как их может оказаться меньше. Но транзакция может и не завершиться если по каким то причинам эти деньги спасить нельзя.
И вторая транзакция должна дождаться, пока первая не закомитится или не откатится.
Если ты используешь общие данные только на чтение, то и блокировки не нужныю
S>>Там где есть запись обычно работают блокировки ReadWriteLock
K>Ужасно тормозная вещь, имеет смысл, толко когда у очень тебя много параллельных чтений и очень мало записей.
Так так в большинстве и существует. Берем ту же БД и транзакции. Там в большинстве блокировки именно на чтение
S>>То есть о каком то замедлении вообще речи не идет. Записей значительно меньше чтения. И ради этого специально тормозить код для межпроцесного взаимодействия.
S>>Не слишком ли жирно?
S>> Есть куча потокобезопасных классов https://docs.microsoft.com/ru-ru/dotnet/api/system.collections.concurrent?view=netcore-3.1
K>Ага, вот сделаем, все коллекции потокобезопасными, а потом не понимаем, почему программа работает медленнее, чем однопоточная.
Прежде чем говорить, ты бы пример привел где эти тормоза. Вот взаимодействие между процессами там дикие тормоза получишь.
K>Я понимаю, что есть куча всяких штук для различной синхронизации. И их количество показывает, что синхронизация, вещь не простая. И они никак не могут меня защитить от случайного обращения к одной области памяти из разных потоков. Я должен их явно ставить.
Не синхронизация, а блокировки. Синхронизация это выполнение кода в одном потоке.
Но если ты используешь асинхронность тот же JavaScript работает на одном потоке, но доступ к данным из разных задач не защищен.
Ничего не надо ставить если используешь только чтение.
K>Но вообще рекомендую попробовать переписать твою прогу в один поток, почему-то мне кажется что у тебя все заработает в разы быстрее...
Угу проходили. У меня на некоторых вещах стоят семафоры, что бы контролировать количество одновременных запросов. Поверь ты не прав.
Многопоточность дает практический пропорциональный прирост количеству потоков (по количество ядер + учет хайпертридинга и на самом деле больше так как внутри могут выполняться асинхронные запросы к диску, БД на другом компе итд)
Просто они нужны, что бы давать отлуп иначе сервер не справляется аля DoS-атака.
Еще раз в большинстве случаев происходит чтение данных , в большинстве случаев к базе данных. Нет проблем с многопоточностью.
Твои проблемы надуманы.