Многопоточная клиент-серверная веб-служба — обеспечение потокобезопасности данных на стороне сервера

Я реализую многопоточный веб-сервис. Поток создается для каждого входящего запроса. Для каждого клиента создается сеанс, и каждый сеанс содержит раздел данных — скажем, дерево DOM. Клиентские запросы в основном будут методами получения/установки, а сервер будет читать/записывать DOM.

Таким образом, данные DOM относятся к каждому клиенту.

Теперь мой вопрос: должен ли сервер рассматривать это дерево DOM как критическую секцию?

В основном вопрос заключается в том, будет ли сценарий, в котором сервер имеет два потока, обслуживающих одного и того же клиента?

Запрос/ответ - это SOAP через tcp. Насколько я понимаю, клиент TCP не может отправлять одновременные запросы, даже если клиент многопоточный. Так что на стороне сервера у меня не будет ситуации, когда два потока предназначены для одного и того же клиента. Пожалуйста, поправьте меня, если я ошибаюсь, я новичок в программировании клиент-сервер tcp/ip.

Спасибо.


multithreading tcp dom soap client-server
person Community    schedule 17.03.2009    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Насколько я понимаю, клиент TCP не может отправлять одновременные запросы, даже если клиент многопоточный.

?? Откуда это пришло?

В HTTP, который, конечно же, основан на TCP, ожидаются одновременные клиентские запросы. RFC2616 говорит, что HTTP-клиенты (браузеры, REST-клиенты и т. д.) ДОЛЖНЫ ограничивать количество одновременных исходящих запросов к определенному серверу до 2. Но это не является жестким требованием протокола, и данное руководство иногда намеренно не соблюдается в некоторых архитектурах.

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

Возможно, конкретная коммуникационная платформа, которую вы используете, не поддерживает несколько одновременных исходящих запросов от клиентов. Но это другое дело.

person Cheeso    schedule 31.03.2009

arrow_upward
0
arrow_downward

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

person Arkaitz Jimenez    schedule 17.03.2009
comment
Я думаю, вы имеете в виду создание и уничтожение потоков, переключение между потоками не проблема. Однако эти накладные расходы можно решить с помощью пулов потоков. - person tstenner; 17.03.2009
comment
пулы потоков помогают, но правильное изменение их размера — рутинная работа. в любом случае, вы увязнете в SOAP даже раньше, чем в многопоточности - person Javier; 17.03.2009
comment
если у вас есть 10000 запросов и у вас есть 10000 потоков, вам нужно изменить контекст потока 10000 раз, чтобы обслуживать каждый из них на 1-ядерной машине, изменить контекст, устранить ошибки кеша из-за изменения стека и многое другое, он хорошо масштабируется только для низких скоростей. - person Arkaitz Jimenez; 17.03.2009
comment
Пулы потоков решают эту проблему. Кроме того, если у вас есть 10000 одновременных запросов, вам, вероятно, понадобится сервер с более чем 1 ядром? - person Cheeso; 01.04.2009
comment
@Cheeso, по-прежнему не масштабируется должным образом, 2 ядра по 5000 на ядро, не очень хорошая сделка. Пулы потоков не решают эту проблему, пулы потоков решают накладные расходы на создание потоков, здесь мы говорим о накладных расходах на переключение потоков. - person Arkaitz Jimenez; 01.04.2009

arrow_upward
0
arrow_downward

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

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

person oo_olo_oo    schedule 25.03.2009