Хотелось бы разобраться в терминах. Часто в книгах, алгоритмах и т.п. в реализации веб-сервера или какого-либо сервера вообще, что упоминается что это именно "асинхронный многопоточный" сервер. То что он "многопоточный" — ладно, тут все понятно, но что оначает здесь именно термин "асинхронный" и бывает ли обратное "синхронный многопоточный" сервер и как это может выглядеть?
Всегда ли обосновано употребление "асинхронный и многопоточный" одновременно и не является ли это тавтологией? Разве многопоточность сама по себе (без дополнительной синхронизации и блокировок, Мониторов) не означает сразу, что она асинхронная? Ведь как раз для того, чтобы сделать синхронизацию потоков и нужно приложить дополнительные усилия использованием sync-блоков object-переменных, блокировок и осуществлением синхронизации? Т.е. я понимаю так что если сделать простое многопоточное приложение без синхронизации — то оно и будет сразу автоматически асинхронным. А вот "синхронное многопоточное" приложение — это уже сложнее, где нужно знать специфику языка, блокировки, уметь использовать синхронизацию. Если здесь все правильно, тогда не понятно почему упоминание "асинхронности" часто встречаю контексте в книгах, примерах, в вакансиях при приеме на работу (извиняюсь линки нет) как что-то особенно крутое, требующее определенного знания и опыта от кандидата. Почему именно "асинхронный многопоточный", нет чтобы написать просто "многопоточный" сервер? Ведь как-раз понятие синхронности требует больших знаний и умений ее реализовать, чем асинхронность. Далее, если правильно рассуждаю, то можно ли за место "асинхронный многопточный" писать как просто "многопоточный".

К тому же бывают ли такие фигни:
1. Синхронный однопоточный сервер (не бывает?)
2. Асинхронный однопоточный сервер (не бывает?)
3. Асихронный многопоточный сервер (проще реализовать?)
4. Синхронный многопоточный сервер (сложнее реализовать?)

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

Я это понимаю так:

PM>Хотелось бы разобраться в терминах. Часто в книгах, алгоритмах и т.п. в реализации веб-сервера или какого-либо сервера вообще, что упоминается что это именно "асинхронный многопоточный" сервер. То что он "многопоточный" — ладно, тут все понятно, но что оначает здесь именно термин "асинхронный" и бывает ли обратное "синхронный многопоточный" сервер и как это может выглядеть?
Бывает. Например, сервер держит коннекшн и по нему же отдаёт результат. Он синхронный, так как следующий запрос в тот же серверный процесс не послать, не получив ответ на предыдущий. Но одновременно можно работать с другими процессами. Пример — telnet server.

PM>Всегда ли обосновано употребление "асинхронный и многопоточный" одновременно и не является ли это тавтологией? Разве многопоточность сама по себе (без дополнительной синхронизации и блокировок, Мониторов) не означает сразу, что она асинхронная? Ведь как раз для того, чтобы сделать синхронизацию потоков и нужно приложить дополнительные усилия использованием sync-блоков object-переменных, блокировок и осуществлением синхронизации?
Здесь Вы немного путаетесь. Синхронизация потоков никакого отношения к синхронности обработки запросов не имеет.
Синхронность — это блокирование потока (клиентского или серверного) от запроса до ответа на него. То есть, синхронный сервер не может одновременно держать в обработке больше запросов, чем количество потоков (threads), которое он использует.

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

PM>А вот "синхронное многопоточное" приложение — это уже сложнее, где нужно знать специфику языка, блокировки, уметь использовать синхронизацию. Если здесь все правильно, тогда не понятно почему упоминание "асинхронности" часто встречаю контексте в книгах, примерах, в вакансиях при приеме на работу (извиняюсь линки нет) как что-то особенно крутое, требующее определенного знания и опыта от кандидата. Почему именно "асинхронный многопоточный", нет чтобы написать просто "многопоточный" сервер? Ведь как-раз понятие синхронности требует больших знаний и умений ее реализовать, чем асинхронность. Далее, если правильно рассуждаю, то можно ли за место "асинхронный многопточный" писать как просто "многопоточный".
Это из-за той же путаницы (см. выше).
Асинхронные сервера, действительно, сложнее в реализации, так как там кроме собственно обработки ещё присутствует механизм очередей, иногда ещё какой-нибудь хитрый диспетчер запросов.

PM>К тому же бывают ли такие фигни:
PM>1. Синхронный однопоточный сервер (не бывает?)
Это, наверное редкость, так как редко нужен сервер на одного клиента одновременно. Не могу придумать пример, хотя. реализовать, конечно, можно.

PM>2. Асинхронный однопоточный сервер (не бывает?)
Однопоточная Workflow-система. Мы такую писали. Но чаще они, всё-таки, многопоточные.
Некоторые почтовые сервера, особенно старые

PM>3. Асихронный многопоточный сервер (проще реализовать?)
Любая современна workflow-система.
Почтовые сервера, которые используют несколько потоков.

PM>4. Синхронный многопоточный сервер (сложнее реализовать?)
Большинство известых серверов
IIS, MSSQL...

PM>>Хотелось бы разобраться в терминах. Часто в книгах, алгоритмах и т.п. в реализации веб-сервера или какого-либо сервера вообще, что упоминается что это именно "асинхронный многопоточный" сервер. То что он "многопоточный" — ладно, тут все понятно, но что оначает здесь именно термин "асинхронный" и бывает ли обратное "синхронный многопоточный" сервер и как это может выглядеть?
V>Бывает. Например, сервер держит коннекшн и по нему же отдаёт результат. Он синхронный, так как следующий запрос в тот же серверный процесс не послать, не получив ответ на предыдущий. Но одновременно можно работать с другими процессами. Пример — telnet server.

Давайте может я по шагам распишу "асинхронно-многопоточную" схему как я ее вижу, а вы скажете где я не прав:
1. Я создаю сервер в котором есть первый (и пока единственный) поток с listener'ом который слушает например на 80 порту;
2. Создаю однопоточного клиента который устанавливает соединение с сервером на 80 порт;
3. Сервер создает второй поток (асинхронным вызовом?) и пришедшего клиента перекидывает с 80 на другой порт > 3000;
Таким образом у нас есть второй поток внутри которого установлено соединение с клиентом.
Вот с этогго места мне не понятно. Если соединение одно, то по нему разве можно слать данные сразу в обе стороны? Тем самым обеспечить особенные условия что пока сервер отсылает отмет на предыдущий запрос — клиент получает его и одновременно шлет следующий запрос? Как возможно чтобы клиент получал данные и одновременно слал новые, ведь клиент у нас однопоточный? В этом месте не очень понятно.

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

PM>Давайте может я по шагам распишу "асинхронно-многопоточную" схему как я ее вижу, а вы скажете где я не прав:
PM>1. Я создаю сервер в котором есть первый (и пока единственный) поток с listener'ом который слушает например на 80 порту;
PM>2. Создаю однопоточного клиента который устанавливает соединение с сервером на 80 порт;
PM>3. Сервер создает второй поток (асинхронным вызовом?) и пришедшего клиента перекидывает с 80 на другой порт > 3000;

Зависит от того как Ваш сервер "слушает". Если, например, Вы используете обычный Accept() обычного System.Net.Sockets.Socket, то по-умолчанию он работает в синхронном режиме. И поток Вашего сервера слушающий 80-й порт блокирован и ничего не может делать до тех пор, пока Accept() не вывалится с сокетом нового соединения..., ну или исключением.

А вот если Вы используете метод BeginAccept(), то это уже асинхронный I/O. И никакой блокировки не будет. После вызова "главный" поток сервера сможет немедленно продолжить заниматься своими делами. Когда же будет установлено новое соединение, то автоматически, в одном из потоков специального thread pool'а, вызовется callback, который Вы передали в параметрах BeginAccept().

PM>Таким образом у нас есть второй поток внутри которого установлено соединение с клиентом.

Соединение оно само по себе. И с потоками никак не связано. То что Вы его процессите привязывая к потоку — всего лишь один из способов работы с I/O. И далеко не самый эффективный...

PM>Вот с этогго места мне не понятно. Если соединение одно, то по нему разве можно слать данные сразу в обе стороны?

Если это TCP-cоединение, например, то без проблем, оно двунаправленное.

PM>Тем самым обеспечить особенные условия что пока сервер отсылает отмет на предыдущий запрос — клиент получает его и одновременно шлет следующий запрос?

Клиент может делать что хочет, всё определяется форматом протокола который Вы реализуете поверх TCP. Тот же HTTP, например, вполне себе поддерживает возможность отсылать запросы пачками независимо от фазы процессинга ответов...

PM>Как возможно чтобы клиент получал данные и одновременно слал новые, ведь клиент у нас однопоточный?

Ну если Вы junior developer, то клиент написанный Вами, скорее всего, всегда тупой и однопоточный А у senior'ов запросто может быть асинхронный и многопоточный

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

PM>Хотелось бы разобраться в терминах. Часто в книгах, алгоритмах и т.п. в реализации веб-сервера или какого-либо сервера вообще, что упоминается что это именно "асинхронный многопоточный" сервер. То что он "многопоточный" — ладно, тут все понятно, но что оначает здесь именно термин "асинхронный"

"Асинхронный" означает, что потоки обрабатывающие запросы к серверу не блокируются на время ожидания исполнения долгоиграющих операций, прежде всего I/O непосредственно соединения.
"Синхронный", соответственно, наоборот, что потоки на вызовах Receive()/Send(), Read()/Write() и т.п. блокируются, и ждут их завершения.

PM>и бывает ли обратное "синхронный многопоточный" сервер

Конечно бывает, и даже доминирует, скорее всего

*Хотя опять-таки надо понимать, что сервер может быть "многоуровневым", то бишь хоститься в другом сервере. Например, IIS внутри весь очень сильно асинхронный, но вот хостящиеся в нём ASP.NET приложения, в большинстве случаев, практически полностью синхронные.

PM>и как это может выглядеть?

Обычный сервер, обрабатывающий установленные соединения путём предоставления каждому из них отдельного потока выполняющего I/O-операции над сокетами (ну и не только сокетами) в синхронной (блокировочной) форме.

PM>Всегда ли обосновано употребление "асинхронный и многопоточный" одновременно

Конечно не всегда. Асинхронность — свойство перпендикулярное многопоточности. Асинхронному серверу может быть вполне достаточно ровно одного потока, как раз потому что он асинхронный

*Асинхронность, собственно, и возникла задолго до появления многопоточности.

PM>и не является ли это тавтологией?

Нет.

PM>Разве многопоточность сама по себе (без дополнительной синхронизации и блокировок, Мониторов) не означает сразу, что она асинхронная?

Нет. Асинхронность требует наличия как способов делать что-то вне (логических) потоков Вашего приложения (например, I/O всякий, которым занимаются отдельные контроллеры), так и способов "внеочередного" уведомления о завершении/статусе этого самого "делания".

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

Неправильно понимаете. Не будет. Опять-таки см. выше.

PM>К тому же бывают ли такие фигни:

Да, все бывают.

PM>>4. Синхронный многопоточный сервер (сложнее реализовать?)
V>Большинство известых серверов
V>IIS, MSSQL...

Ну здрасьте, приехали. Вот как раз эти товарищи вполне себе очень сильно асинхронные.

Тот же IIS может запросто десятки тысяч соединений одновременно держать. Это приложения что хостятся внутри IIS'а зачастую синхронные и портят малину. Однако в том же ASP.NET, например, есть встроенные возможности асинхронной обработки. И если их использовать (грамотно ), то всё будет просто летать, и сервер станет асинхронным уже с ног до головы.

D>Нет. Асинхронность требует наличия как способов делать что-то вне (логических) потоков Вашего приложения (например, I/O всякий, которым занимаются отдельные контроллеры), так и способов "внеочередного" уведомления о завершении/статусе этого самого "делания".

Но я понимаю чтобы делать асинхронный ввод/вывод внутри потоков (например при обращении клиента считывать локальный файл) то для этого нужно запускать еще потоки с call-back'ами внутри уже нашего созданного потока для соединения, верно? Т.е. "многопоточный сервер" превращается в "многопоточный сервер с многопоточными операциями внутри каждого потока" — это и есть асинхронный? Если я правильно понял, то давайте рассмотрим второй вариант, где наш сервер не делает никаких локальных операций чтения из файлов, а просто принимает входящие соединения и сразу на них отвечает, то такой сервер не может быть асинхронным поскольку у него и операций-то блокирования внутри нет (из-за отсутствия чтения с файлов) или может?

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

D>>Нет. Асинхронность требует наличия как способов делать что-то вне (логических) потоков Вашего приложения (например, I/O всякий, которым занимаются отдельные контроллеры), так и способов "внеочередного" уведомления о завершении/статусе этого самого "делания".

PM>Но я понимаю чтобы делать асинхронный ввод/вывод внутри потоков (например при обращении клиента считывать локальный файл) то для этого нужно запускать еще потоки с call-back'ами внутри уже нашего созданного потока для соединения, верно? Т.е. "многопоточный сервер" превращается в "многопоточный сервер с многопоточными операциями внутри каждого потока" — это и есть асинхронный? Если я правильно понял, то давайте рассмотрим второй вариант, где наш сервер не делает никаких локальных операций чтения из файлов, а просто принимает входящие соединения и сразу на них отвечает, то такой сервер не может быть асинхронным поскольку у него и операций-то блокирования внутри нет (из-за отсутствия чтения с файлов) или может?


Зачем нужна асинхронность при многопоточности.

Давай отвлечёмся от многих потоков. Пусть потоков будет два. И пусть это будет клиентское приложение.

Первый поток — главный — это интерфейс с пользователем.
Если это не консоль, а GUI, то — понятное дело, он асинхронный. На него валятся разнообразные сообщения от оконной среды, часть из которых (вперемешку) — активность пользователя.
В цикле прокачки сообщений они распасовываются и трактуются как потоки данных.
Консоль же, обычно, бывает именно синхронной. Вывели очередную порцию текста, ждём очередную строчку от пользователя. А уж как там терминал устроен, есть ли в нём ответный поток или нет, для логики программы безразлично. (Запросто можно сделать, чтоб не было потока. Тогда, если нажимать клавиши, когда никто не ждёт, — они будут просто игнорироваться).

Второй поток — общение по проводу.
Синхронный работает так:
— получил задание от интерфейсного потока (в самом простом виде это "ррработать!")
— дождался соединения
— периодически зависая на ожиданиях, что-то там передавал-получал
— завершил соединение
— отчитался перед интерфейсным потоком
— возможно, пошёл на второй круг

Теперь представь, что интерфейсный поток захотел прервать сеанс связи. У него ничего не выйдет, пока синхронный кукует внутри операции ввода-вывода. Разве что тупо прибить поток.

Для этого и делают асинхронный IO. Как минимум, мы ждём сразу два события — завершение операции (данные получены; данные отправлены) и появление ц/у от хозяина.
При этом рабочий поток может быть устроен как конечный автомат с циклом прокачки и колбеком, вызываемым из этого цикла. А может в виде как-бы синхронного потока общего вида, в котором у всех операций гарантированное время отклика на сигналы хозяина.
То есть,
— операции ожидания обязательно ждут ещё и прерывающее событие
— операции ввода-вывода выполняются, только когда есть гарантии
— любые циклы и длинные вычисления периодически смотрят на прерывающее событие

Собственно говоря, у рабочего потока (thread) здесь ровно два потока данных (data flow) — сеанс связи и прерывания хозяина.
До полноценной многопоточности это не дотягивает.
В отличие от GUI, где обслуживается сразу много потоков данных, а за счёт достаточно быстрого отклика создаётся впечатление одновременности. Но там такая же одновременность, как многозадачность на одноядерном процессоре.


Всё сказанное выше справедливо и тогда, когда рабочих потоков много. И для сервера тоже справедливо.
Например, главный поток следит за изменением конфигурации и за деятельностью администратора.

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

PM>Но я понимаю чтобы делать асинхронный ввод/вывод внутри потоков (например при обращении клиента считывать локальный файл) то для этого нужно запускать еще потоки с call-back'ами внутри уже нашего созданного потока для соединения, верно?

При асинхронной работе нам не нужен отдельный поток для каждого соединения. Во многих случаях для всех callback'ов вообще одного-единственного потока хватает за глаза. С этого, собственно, всё и начиналось...

PM>Т.е. "многопоточный сервер" превращается в "многопоточный сервер с многопоточными операциями внутри каждого потока" — это и есть асинхронный?

Нет. Операции как раз однопоточные, обычно. Их кусочки (callback'и) могут исполняться в контексте разных потоков, но исполнение при этом всё равно последовательное, и эквивалентно соответствующему запуску в одном потоке.

PM>Если я правильно понял, то давайте рассмотрим второй вариант, где наш сервер не делает никаких локальных операций чтения из файлов, а просто принимает входящие соединения и сразу на них отвечает, то такой сервер не может быть асинхронным поскольку у него и операций-то блокирования внутри нет (из-за отсутствия чтения с файлов) или может?

Ещё как может. Ведь всегда есть I/O-операции собственно соединения. Они одни из самых длительных и, соответственно, критичных. Бо, например, скорость клиента на 56K модеме, да с другой стороны планеты очень печальная

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

PM>>>4. Синхронный многопоточный сервер (сложнее реализовать?)
V>>Большинство известых серверов
V>>IIS, MSSQL...

D>Ну здрасьте, приехали. Вот как раз эти товарищи вполне себе очень сильно асинхронные.

D>Тот же IIS может запросто десятки тысяч соединений одновременно держать. Это приложения что хостятся внутри IIS'а зачастую синхронные и портят малину. Однако в том же ASP.NET, например, есть встроенные возможности асинхронной обработки. И если их использовать (грамотно ), то всё будет просто летать, и сервер станет асинхронным уже с ног до головы.
Про IIS — да, согласен, это я ошибся. IIS, действительно, внутри себя весь асинхронный.
А вот MSSQL — точно синхронный, по крайней мерп database engine. Там на любой коннекшн создаётся процесс, который его и обрабатывает.

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

PM>>>Хотелось бы разобраться в терминах. Часто в книгах, алгоритмах и т.п. в реализации веб-сервера или какого-либо сервера вообще, что упоминается что это именно "асинхронный многопоточный" сервер. То что он "многопоточный" — ладно, тут все понятно, но что оначает здесь именно термин "асинхронный" и бывает ли обратное "синхронный многопоточный" сервер и как это может выглядеть?
V>>Бывает. Например, сервер держит коннекшн и по нему же отдаёт результат. Он синхронный, так как следующий запрос в тот же серверный процесс не послать, не получив ответ на предыдущий. Но одновременно можно работать с другими процессами. Пример — telnet server.

PM>Давайте может я по шагам распишу "асинхронно-многопоточную" схему как я ее вижу, а вы скажете где я не прав:
PM>1. Я создаю сервер в котором есть первый (и пока единственный) поток с listener'ом который слушает например на 80 порту;
PM>2. Создаю однопоточного клиента который устанавливает соединение с сервером на 80 порт;
PM>3. Сервер создает второй поток (асинхронным вызовом?) и пришедшего клиента перекидывает с 80 на другой порт > 3000;
PM>Таким образом у нас есть второй поток внутри которого установлено соединение с клиентом.
PM>Вот с этогго места мне не понятно. Если соединение одно, то по нему разве можно слать данные сразу в обе стороны?
Да, можно. Почему бы нет? Протокол HTTP это, по крайней мере, позволяет (в версии HTTP 1.1, RFC 2616 раздел 8.1.1).

PM>Тем самым обеспечить особенные условия что пока сервер отсылает отмет на предыдущий запрос — клиент получает его и одновременно шлет следующий запрос? Как возможно чтобы клиент получал данные и одновременно слал новые, ведь клиент у нас однопоточный?
Например, так:
— Послать первый запрос
— Послать второй запрос
— Ждать ответа
— Определить, на какой запрос это ответ и обработать его
— Ждать ещё ответа
— Определить, на какой запрос это ответ и обработать его

PM>В этом месте не очень понятно.
Тут Вы немного смешали две вещи: асинхронность сервера и асинхронность взаимодействия с клиентом.
Взаимодействие по HTTP в рамках одного соединения в Вашем сценарии, видимо, синхронное (хотя это не обязательно даже при однопоточном клиенте — пример выше). В то же время, никто не мешает серверу поставить этот запрос в очередь (не отпуская соединение), обработать другой запрос другого клиента, потом вернуться к этому, обработать его и отослать ответ. При этом работа сервера будет асинхронной.

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

V>А вот MSSQL — точно синхронный, по крайней мерп database engine.

Последний синхронный MSSQL был 6.5 С семёрки/2000 всё асинхронное.

V>Там на любой коннекшн создаётся процесс, который его и обрабатывает.

Ничего подобного. Там кооперативные шедулеры, по одному на каждое процессорное ядро, пул рабочих потоков до 255 штук. Лимит на число соединений 32767.

*У 64-битного может даже и поболее всё...

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

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

V>>А вот MSSQL — точно синхронный, по крайней мерп database engine.

D>Последний синхронный MSSQL был 6.5 С семёрки/2000 всё асинхронное.

V>>Там на любой коннекшн создаётся процесс, который его и обрабатывает.

D>Ничего подобного. Там кооперативные шедулеры, по одному на каждое процессорное ядро, пул рабочих потоков до 255 штук. Лимит на число соединений 32767.
D>*У 64-битного может даже и поболее всё...
Не могу согласится. Все потоки, которые управляются этими шедулерами обрабатывают запросы всё равно синхронно. Ведь с момента, как запрос взят на обработку и до окончания обработки за него отвечает один выделенный worker.
То есть, по сути это как раз синхронная многопоточная обработка. А UMS — просто способ управления пулами рабочих потоков.

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

D>>Последний синхронный MSSQL был 6.5 С семёрки/2000 всё асинхронное.
V>>>Там на любой коннекшн создаётся процесс, который его и обрабатывает.
D>>Ничего подобного. Там кооперативные шедулеры, по одному на каждое процессорное ядро, пул рабочих потоков до 255 штук. Лимит на число соединений 32767.
V>Не могу согласится.

А я ещё раз повторю: соединения не привязываются к потоку и обрабатываются асинхронно. Поэтому их лимит больше лимита рабочих потоков.

V>Ведь с момента, как запрос взят на обработку и до окончания обработки за него отвечает один выделенный worker.

Вот именно, "запрос", а не "соединение".

V>Все потоки, которые управляются этими шедулерами обрабатывают запросы всё равно синхронно.

Неа. Далеко не всё синхронно. Например есть асинхронный I/O, и его callback'и обрабатываются в том потоке, который выполняет шедулинг на момент завершения операции.

V>То есть, по сути это как раз синхронная многопоточная обработка.

См. выше. Даже запросы асинхронность имеют, хотя и несколько ограниченную.

*И это мы ещё не касались режима с fiber'ами вместо thread'ов

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

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

D>>>Последний синхронный MSSQL был 6.5 С семёрки/2000 всё асинхронное.
V>>>>Там на любой коннекшн создаётся процесс, который его и обрабатывает.
D>>>Ничего подобного. Там кооперативные шедулеры, по одному на каждое процессорное ядро, пул рабочих потоков до 255 штук. Лимит на число соединений 32767.
V>>Не могу согласится.
D>А я ещё раз повторю: соединения не привязываются к потоку и обрабатываются асинхронно. Поэтому их лимит больше лимита рабочих потоков.

V>>Ведь с момента, как запрос взят на обработку и до окончания обработки за него отвечает один выделенный worker.
D>Вот именно, "запрос", а не "соединение".

V>>Все потоки, которые управляются этими шедулерами обрабатывают запросы всё равно синхронно.
D>Неа. Далеко не всё синхронно. Например есть асинхронный I/O, и его callback'и обрабатываются в том потоке, который выполняет шедулинг на момент завершения операции.

V>>То есть, по сути это как раз синхронная многопоточная обработка.
D>См. выше. Даже запросы асинхронность имеют, хотя и несколько ограниченную.
D>*И это мы ещё не касались режима с fiber'ами вместо thread'ов

Усомнился в актуальности своих знаний и полез читать современные источники информации, в результате вынужден констатировать, что Вы правы.
Действительно, он внутри себя очень даже асинхронный. И он совершенно одинаково асинхронный при работе с threads и fibers.

Зато теперь ясно, что примером синхронного многопоточного сервера может служить MSSQL 6.5.

D>А я ещё раз повторю: соединения не привязываются к потоку и обрабатываются асинхронно. Поэтому их лимит больше лимита рабочих потоков.

Как это может быть? Т.е. к серверу созданы 100 соединений от клиентов по которым идет прием-передача данных, но эти соединения могут обрабатываться всего одним программным потоком? Каким образом это может происходить? Какой-нибудь наглядный пример можно? Как это выглядит? Можно даже не вдаваться в детали кода, просто в общих чертах описать словами схематично как-нибудь?

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

PM>Как это может быть? Т.е. к серверу созданы 100 соединений от клиентов по которым идет прием-передача данных, но эти соединения могут обрабатываться всего одним программным потоком?
Ну почему одним. Например, 10ю потоками.
PM>Каким образом это может происходить? Какой-нибудь наглядный пример можно? Как это выглядит?
Отлично выглядит.
PM>Можно даже не вдаваться в детали кода, просто в общих чертах описать словами схематично как-нибудь?
Вот у нас поток "освободился". Он идет в очередь запросов, извлекает из нее запрос, обрабатывает его, отправляет результат в соединение и так по кругу.
Клиент получает ответ, думает, отправляет новый запрос. Всё это время никакой поток не ждет его реакции — он занимается своими делами. Как только клиент отправил запрос, он снова попадет в очередь запросов и будет в ней стоять, пока очередной поток не освободится и не выполнит запрос.
Это будет работать даже на 1м потоке.

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

PM>Хотелось бы разобраться в терминах. Часто в книгах, алгоритмах и т.п. в реализации веб-сервера или какого-либо сервера вообще, что упоминается что это именно "асинхронный многопоточный" сервер. То что он "многопоточный" — ладно, тут все понятно, но что оначает здесь именно термин "асинхронный" и бывает ли обратное "синхронный многопоточный" сервер и как это может выглядеть?
PM>Всегда ли обосновано употребление "асинхронный и многопоточный" одновременно и не является ли это тавтологией? Разве многопоточность сама по себе (без дополнительной синхронизации и блокировок, Мониторов) не означает сразу, что она асинхронная? Ведь как раз для того, чтобы сделать синхронизацию потоков и нужно приложить дополнительные усилия использованием sync-блоков object-переменных, блокировок и осуществлением синхронизации? Т.е. я понимаю так что если сделать простое многопоточное приложение без синхронизации — то оно и будет сразу автоматически асинхронным. А вот "синхронное многопоточное" приложение — это уже сложнее, где нужно знать специфику языка, блокировки, уметь использовать синхронизацию. Если здесь все правильно, тогда не понятно почему упоминание "асинхронности" часто встречаю контексте в книгах, примерах, в вакансиях при приеме на работу (извиняюсь линки нет) как что-то особенно крутое, требующее определенного знания и опыта от кандидата. Почему именно "асинхронный многопоточный", нет чтобы написать просто "многопоточный" сервер? Ведь как-раз понятие синхронности требует больших знаний и умений ее реализовать, чем асинхронность. Далее, если правильно рассуждаю, то можно ли за место "асинхронный многопточный" писать как просто "многопоточный".

PM>К тому же бывают ли такие фигни:
PM>1. Синхронный однопоточный сервер (не бывает?)
PM>2. Асинхронный однопоточный сервер (не бывает?)
PM>3. Асихронный многопоточный сервер (проще реализовать?)
PM>4. Синхронный многопоточный сервер (сложнее реализовать?)

Синхронный сервер — это сервер который знает, в какой момент времени к нему, придет сообщение от клиента.
Асинхронный сервер — это сервер который не знает, в какой момент времени к нему, придет сообщение от клиента.

PM>1. Синхронный однопоточный сервер (не бывает?)
Бывает делали в технической системе когда было зарание известно в какой момент времене с датчика придет информация.

Все сервера которые работают с людьми, работают в асинхронном режиме, не известно когда человек захочет послать запрос на сервер.

Не нужно подменять понятия блокированный/не блокированный режим работы сокета, с понятиями синхронный/асинхронный режим работы.

А вот однопоточный или многопоточный это как реализован сервер внутри.

Тоесть сервер с самой сложно реализацией.
PM>3. Асихронный многопоточный сервер (проще реализовать?)

PM>>Как это может быть? Т.е. к серверу созданы 100 соединений от клиентов по которым идет прием-передача данных, но эти соединения могут обрабатываться всего одним программным потоком?
S>Ну почему одним. Например, 10ю потоками.
PM>>Каким образом это может происходить? Какой-нибудь наглядный пример можно? Как это выглядит?
S>Отлично выглядит.
PM>>Можно даже не вдаваться в детали кода, просто в общих чертах описать словами схематично как-нибудь?
S>Вот у нас поток "освободился". Он идет в очередь запросов, извлекает из нее запрос, обрабатывает его, отправляет результат в соединение и так по кругу.
S>Клиент получает ответ, думает, отправляет новый запрос. Всё это время никакой поток не ждет его реакции — он занимается своими делами. Как только клиент отправил запрос, он снова попадет в очередь запросов и будет в ней стоять, пока очередной поток не освободится и не выполнит запрос.
S>Это будет работать даже на 1м потоке.

Если здесь свего один поток, кто тогда будет заниматься построением очереди запросов и где устанавливается/чем регулируется длина такой очереди?

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

PM>Если здесь свего один поток, кто тогда будет заниматься построением очереди запросов и где устанавливается/чем регулируется длина такой очереди?
Длина очереди определяется только соотношением между скоростью поступления запросов и скоростью их выполнения.
Построением очереди может тоже заниматься тот же самый поток, в промежутках между обслуживанием запросов.
Либо выделяем для этого отдельный поток, который будет висеть на wait всех сокетов. В HTTP так примерно и делается.