Комментарии 22
Здравствуйте, спасибо за статью! Вы пишете:
Многопоточность незаменима тогда, когда необходимо, чтобы графический интерфейс продолжал отзываться на действия пользователя во время выполнения некоторой обработки информации.
Скорее, не незаменима, а является одним из способов обеспечения отзывчивости интерфейса. Например, главный поток в браузере может успеть и страницу отрендерить, и сделать еще какие-то вычисления, главное вовремя возвращаться к рендерингу страницы.
Спасибо, в следующей статье формулировки будут точнее
у автора всё нормально изложено, технически пример на гтк - связь X11/SDL/glfw - все эти библиотеки кто прокидывает калбеки, кто прокидывает концы опроса с thread_pool, а на Иксах без калбека или трид пула на Input придётся делать как раз одно из двух что предоставляет даже гтк(повторы, задержка, поэтому придётся делать своё -x11 ), на виндовсе асинхронная обработка уже преврщенная в функцию, а так да чтоб и то и то работало
Технически главный поток в браузере оффлоадит как минимум все сетевые операции на пул тредов работающих с сетью(BrowserThread::IO). Так что без многопоточности он бы колом вставал во время фетча, как при старом (не)добрым синхронном Аяксе и никакой отзывчивости бы не было и в помине.
как при старом (не)добрым синхронном Аяксе
как AJAX может быть синхронным, если там первая буква A как раз означает asynchronous?
И даже древний XMLHttpRequest из IE 5 (упокой господь его душу) был асинхронным, там вешался коллбэк на onreadystatechange, и основной поток рендеринга страницы не блокировался на время сетевого I/O.
Так что без многопоточности он бы колом вставал во время фетча
I/O асинхронность в целом возможна и при использовании одного потока с использованием неблокирующих вызовов и демультиплексирования. Единственное исключение - стандартные getaddrinfo/gethostbyname не имеют неблокирующей версии (но его функционал можно и ручками реализовать асинхронно, да и в glibc была реализация одного из них с префиксом _a), плюс чтение со всяких сетевых ФС типа NFS и SMB часто не может быть асинхронным из-за особенностей реализации, так сказать.
А почему это в хабе разработки под винду? Ожидал что-то кроссплатформенное, а тут чистый pthread - тоже полезно в образовательных целях, но не так интересно. И если нужно именно распараллелить работу используя тредпул - в практических целях лучше посмотреть на TBB или OpenMP, хотя знать, как под капотом работают потоки, конечно стоит.
Хорошо, что чётко расписали отличие многопоточности и асинхронности - часто можно обойтись и без тредов.
Спасибо за статью!
Ещё было бы интересно почитать про тренды в контексте си это про добавленный заголовок в си11 -- threads.h
Понятно, что там практически тоже самое, как в posix тредах. но инфы про его использование практически нет. На сколько он поддержан компиляторами и кроссплатформенный
У самого руки не доходят пощупать, так что буду рад если найдете время и самое главное желание в этом разбраться)
В ближайшее время планировал написать много статей, до этой скорее всего в ближайшую неделю руки тоже дойдут
Он очень мало где поддерживается. Формат практически продавили в стандарт, но обрезали при этом по самое немогу, поэтому никто его поддержкой не заморачивается.
Вроде как запилили в glibc 2.28 и VS 2022 17.8p2 , так что на основных платформах есть.
Тут вообще сложно привести пример, но я попытался, для меня вообще все примеры одинакого сложно придумывать, а потом их говнокодить.
Прям как в анекдоте про орла с экипажем. Зачем же так напрягаться то?
По нажатии кнопки создается поток который просто выводит числа от 1 до 10. То есть если нажать два раза одновременно то
Нажать два раза одновременно звучит прикольно!
Мьютекс - это некий механизм который изолирует shared данные когда их использует один поток дабы избежать гонок данных.
Точно? Именно когда их использует только один поток?
Вместо создания нового потока для каждой задачи используйте пул потоков
Я так понимаю вы рекомендуете каждый раз писать свою(вашу) самодельную реализацию пула потоков?
В C можно использовать функции pthread вместе с библиотеками для асинхронной работы
мне казалось что библиотека с pthread-ами и есть библиотека для асинхронной работы в Си.
...
Очень прикольная статья, как тут плюс не поставить!
Для многопоточности в C и C++ предназначена библиотека posix-thread.
А где в стандартах C/C++ что-то о posix-thread?
Объясню - каждая система состоит из процессов, а процесс состоит из потоков
Отличное объяснение. Прям сразу все на свои места ставит.
Про поточные библиотеки в плюсах уже сказали, остальная часть статьи изложена в книге Бутенхофа Programming with POSIX threads
Поток блокируется до тех пор, пока другой поток не вызовет сигнал (pthread_cond_signal или pthread_cond_broadcast).
Тут очень важно добавить, что при ожидании возможны так называемые spurious wakeups - когда никто не делал pthread_cond_signal, а pthread_cond_wait все равно завершит свою работу и разблокирует поток.
Поэтому хорошей практикой считается использоваться conditional variables вместе с булевым флагом/предикатом:
When using condition variables there is always a Boolean predicate involving shared variables associated with each condition wait that is true if the thread should proceed. Spurious wakeups from the pthread_cond_timedwait() or pthread_cond_wait() functions may occur. Since the return from pthread_cond_timedwait() or pthread_cond_wait() does not imply anything about the value of this predicate, the predicate should be re-evaluated upon such return.
Молодец! Это я, alexeev_dev из телеграма. Отличнейшая статья!
Многопоточное программирование на C