TCP: правда ли, что send/write нельзя вызывать из разных потоков, иначе перепутается содержимое буферов?

Question

[Vermut756]

Я строю довольно сложную клиент-серверную систему, поэтому хотелось бы применить многопоточность, скажем на клиенте в одном потоке отправлять heartbeat, а в другом - команду серверу, и при этом использовать только один сокет.
Но нормальное ли это решение?

Для начала поясню, о какой именно путанице я говорю.

Итак, псевдокод то что я отправляю:

send("123456"); // Поток 1
send("ABCDEF");  // Поток 2

Я знаю, что в итоге на принимающую сторону может прийти вот такое:

ABCDEF
123456

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

Но один человек на форуме, если я его правильно понял, утверждает, что все еще хуже.
Говорит, что якобы могут перепутаться сами байты в сообщениях, то есть может прийти и такое:

ABC45F
123DE6

Правда ли это?
Когда я пробовал создать много потоков, то этого я НЕ наблюдал, сообщений было много, но ни в одном из них байты не смешивались с байтами из других сообщений.
Но не буду надеяться на авось, вот на всякий случай спрашиваю.

Операционная система:
Windows, разных версий и разрядностей, но только Windows, и на сервере и на клиентах.

Answer 1

[sitev_ru]

Добавь мютексы:

mutex my_mutex;
void my_send() {
	my_mutex.lock();
	// тут отправляем в сокет
	my_mutex.unlock();
}
void my_recv() {
	my_mutex.lock();
	// тут читаем из сокета
	my_mutex.unlock();
}

Эти команды пропиши и на сервере и на клиенте

Comments

[Vermut756]

А recv-то зачем, ведь он у меня будет только в 1 потоке.
Всего 3 потока - 1 recv и 2 send.

[sitev_ru]

не вдавался в детали, смотри по ситуации

[Vermut756]

sitev_ru: Ну, я еще поэкспериментирую, но если у меня и без мьютексов все работает?

[res2001]

Vermut756: Мьютексы обеспечивают синхронизацию между потоками. Т.е. пока один поток отправляет, другой будет ждать окончания отправки и только потом начнет отправлять.
Вообще, раз уж используете потоки, то примитивы синхронизации необходимо знать. И уметь применять в нужных местах.
Только пример не правильный - используемый мьютекс в обоих потоках должен быть один. А в таком виде при любом вызове функции создается локальный мьютекс с помощью которого никакой синхронизации не добиться. Т.е. переменные мьютекса должны быть либо статическими в функции, либо глобальными.

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

[sitev_ru]

"Только пример не правильный" - блин, точно, подредактировал )

[res2001]

sitev_ru: Можно сделать отдельные мьютексы на прием и передачу, так будет более продуктивно, я думаю.

Answer 2

[lega]

Если используется кеш на уровне ОС, а не на уровне приложения, то все будет ок.
Для надежности и сокращения ошибок, можете сделать 3-й поток под отправку, и уже в него складывать все данные для отправки.

Comments

[Vermut756]

О каком кеше речь?

Answer 3

[15432]

На коротких сообщениях (меньше MTU) такого не будет. Вот если будете в одном из потоков слать несколько килобайт, может возникнуть ситуация, когда части сообщений перемешаются.
Пример:
- поток 1 посылает 10000 байт, send вернул 2048
- поток 2 в это время записывает короткую команду в этот же сокет
- поток 1 досылает оставшиеся байты, но перед ними уже влезла команда из потока 2

Почему бы не добавить мьютексы? Или несколько сокетов?

Comments

[Vermut756]

А насколько легко пронаблюдать эту ситуацию в рамках эксперимента?
Несколько сокетов нельзя, потому что одном потоке у меня payload, а во втором heartbeat, обеспечивающий надежность соединения именно для этого payload.
С мьютексами никогда не работал.

[15432]

Vermut756: попробуйте повторить ваш пример с цифрами и буквами, но на размерах порядка 20 КБ, только не на локалке а на тормознутом соединении типа 3G.

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

Если без мьютексов и очередей - можно вообще всё в один поток сделать. Я делал.

[Vermut756]

15432: 3G как-то нет под рукой. А мобильный интернет - это надо на UNIX переписывать.
Wi-Fi есть, но он не такой уж и тормознутый наверно? Скорость скажем 20, 40 мегабит в секунду, достаточно или еще хуже?
А программы вроде NetLimiter вообще насколько имеют смысл при подобных тестах?
Мне в любом случае потом еще и саму систему испытывать, как она себя ведет не только при обрыве, но и при торможении.

можно вообще всё в один поток сделать. Я делал.

Хех, мне стабильность нужна железобетонная. Как у скайпа и аськи.
Следовательно, как минимум 2 типа сообщений надо слать - собственно сами полезные сообщения и еще heartbeat.
Но может даже удобнее будет, если отказаться от параллельной их отправки?

[15432]

И в один поток можно стабильно всё сделать. На неблокирующих сокетах. У меня однопоточный HTTP прокси на сотне клиентов не тормозит.
Да, NetLimiter на принимающей стороне сгодится для тестов. Лишь бы добиться, чтоб send не все данные разом отправил. Даже интересно, что получится.

[Дмитрий]

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

А если по делу, зачем вам несколько тредов в вашем случае? Если ваша система, как вы пишете, действительно сложная, используйте асинхронные сокеты, единственный тред и очередь сообщений; намного меньше геморроя получите. Блокирующие сокеты на сложной системе -- путь в никуда, и тормоза, растущие в геометрической прогрессии от количества подключений.

Answer 4

[Владимир Дубровин]

Перепутаться содержимое именно в send()/write() не должно, т.к. вывод не буферизирован, функция выполняется за один системный вызов. Но send()/write() в любом случае могут отправить не полный буфер данных, обязательно надо контролировать возвращаемое значение. И доотправлять неотправленное. Поскольку одну команду может быть придется отправлять за несколько операций send()/write() - содержимое в разных потоках может перемешаться. Правда на практике такое (отправка неполного буфера) в Windows мне не встречалось (а вот в POSIX системах это достаточно обычное явление). Но пологаться на это, разумеется, не стоит и лучше, как уже говорилось, использовать критические секции или мутексы для синхронизации отправки данных.