Работа с сокетами в Linux 2.6 является thread-safe, т.е. write() и read() для одного и того же сокета можно делать из разных потоков и если можно, то это обеспечивается блокировками mutex/spin-lock или реализовано через lock-free?

Dimitry SibiryakovWrite() и read() это два совершенно разных процесса, их всегда можно было делать из разных
потоков. А вот можно ли одновременно из разных потоков делать send() в один и тот же сокет
- вопрос гораздо интереснее.

Да это тоже интересует, если кто знает?

Anatoly MoskovskyВ 3.2.39 (думаю это относится и к 2.6.* и 3.*) при записи/чтении сокета производится эксклюзивная блокировка структур сокета с усыплением ждущего потока.
Т.е. в теории должно быть потокобезопасно для любых комбинаций: read/read read/write write/write.
Как оно на практике - не знаю, т.к. код сокетов обернут в обобщенный код реализующий дескрипторы, в котором могут быть свои заморочки ( но думаю что нет ).
В смысле, что нет заморочек или нет потокобезопасности? :)
Т.е. потокобезопасность именно lock-based и именно на мьютексе (не спинлок), а есть какие-то ссылки или цитаты из стандарта POSIX (POSIX.1-2001/SUSv3) на эту тему или хотя бы откуда это известно?

Anatoly MoskovskyСокеты в Linux thread-safe?В смысле, что нет заморочек или нет потокобезопасности? :)
Заморочек :)
Сокеты в Linux thread-safe?Т.е. потокобезопасность именно lock-based и именно на мьютексе (не спинлок), а есть какие-то ссылки или цитаты из стандарта POSIX (POSIX.1-2001/SUSv3) на эту тему или хотя бы откуда это известно?
Да, мьютекс. Из исходников ядра известно. :)
А как по стандарту - не в курсе.

Вообще, если бы не было потокобезопасности в сисколах, то юзерспейс мог бы легко повредить структуры ядра. Т.е. тут два варианта потокобезопасного поведения: либо параллельные вызовы сериализуются, либо выполняется только один из них, а остальные возвращают ошибку.
Какой из этих вариантов применяется для write/write - вы можете легко проверить экспериментом.
Но как я выше сказал, для сокетов (да, забыл сказать - я смотрел в код TCP-сокетов, для других протоколов может быть по другому) - идет сериализация в самом сокете, а вышележащий код, вплоть до верхнего уровня sys_write, скорее всего вообще ничего потоко-опасного не делает и не нуждается в доп. синхронизации.
Интересно, а почему они просто мьютекс поставили, а не допустим очередь защищенную мьютексом?
Ждать отправки то как бы не обязательно - кинули в очередь и пошли дальше выполнятся. И блокировка держалась бы намного меньше. Или там внутри все таки есть очередь?

Anatoly MoskovskyСокеты в Linux thread-safe?Интересно, а почему они просто мьютекс поставили, а не допустим очередь защищенную мьютексом?
Естественно там очередь. Даже по умолчанию работает алгоритм Нэйгла, при котором пакеты отправляются не сразу, а при определенных условиях.
Так что конечно же при захвате мьютекса речь не идет про ожидание физической отправки данных.
Т.е. в принципе сокеты можно использовать, как потоко-безопасную lock-based очередь (много производителей - много потребителей) для обмена данными между процессами, причем с возможностью дальнейшего разнесения процессов по разным серверам соединенным по сети?
Т.е. в одном процессе много потоков пишут в один и тот же сокет, а в другом процессе много потоков вычитывают данные из одного и того же сокета и таким образом получаем балансировку нагрузки.

vromanovСокеты в Linux thread-safe?,

Ну да.. Один процесс вычитает первую половину сообщения, а другой вторую половину сообщения :)
Также и с записью. :)

Не, так не работает..
Ну сокеты по разным протоколам работают, например передача UDP-датаграмм - всегда получаются завершенные сообщения, или нет? :)

А с TCP я так понимаю придеться с обеих сторон по одному потоку работать с одним сокетом, и с обеих сторон понадобиться по потоко-безопасной очереди для работы множества потоков с этим сокетом?