UDP sendmsg IP_TOS, установка класса QoS в Linux atomic? (блокировка / ошибка сигнала)

Сценарий: два потока отправляют UDP на один и тот же сокет, и поток 1 хочет установить другой класс diffserv / QoS, чем поток 2. Мы решили эту проблему ранее, обернув вызовы sendto () в мьютекс и выполнив setsockopt () соответствующего класса QoS до и после sendto () (а затем разблокировать мьютекс).

Мы получили тупик / зависание в редких случаях (из-за взаимодействия с сигналом), используя это решение, и мой вопрос заключается в следующем — можем ли мы полностью удалить мьютекс, если вместо этого мы отправим требуемый класс QoS в качестве вспомогательных данных в вызове sendmsg () ? Чтобы уточнить, является ли sendmsg () атомарным, поэтому дейтаграммы будут отправляться с использованием правильного класса QoS, и не рискует ли вызовы sendmsg () из потоков 1 и 2 мешать друг другу?

Я нашел похожие вопросы по SO, поэтому я знаю, что обычная sendmsg () одной дейтаграммы UDP на одном сокете является «атомарной», но вопрос в том, является ли весь вызов, включая временное изменение битов QoS для сокета, атомарным, как это видно из поток пользовательского пространства?

Соответствующий патч в ядре Linux таков:

commit aa6615814533c634190019ee3a5b10490026d545
Author: Francesco Fusco <[email protected]>
Date:   Tue Sep 24 15:43:09 2013 +0200

ipv4: processing ancillary IP_TOS or IP_TTL

If IP_TOS or IP_TTL are specified as ancillary data, then sendmsg() sends out
packets with the specified TTL or TOS overriding the socket values specified
with the traditional setsockopt().

The struct inet_cork stores the values of TOS, TTL and priority that are
passed through the struct ipcm_cookie. If there are user-specified TOS
(tos != -1) or TTL (ttl != 0) in the struct ipcm_cookie, these values are
used to override the per-socket values. In case of TOS also the priority
is changed accordingly.

Two helper functions get_rttos and get_rtconn_flags are defined to take
into account the presence of a user specified TOS value when computing
RT_TOS and RT_CONN_FLAGS.

Signed-off-by: Francesco Fusco <[email protected]>
Signed-off-by: David S. Miller <[email protected]>