MulticastSocket join/leave group, send, receive thread-safety

Question

I was reasoning about multicast socket thread-safety in my application. First of all I've multiple threads sharing the same multicast socket instance, this multicast socket is used to join different groups on the same port. Here are my questions:

Do I have to synchronize calls to joinGroup() and leaveGroup() methods?
Do I have to synchronize calls to send() and receive() methods which uses always new istance of datagram packet as parameter?

Here's a code example of the 2nd question:

/* SEND METHOD EXAMPLE. */
    DatagramPacket sndPckt = new DatagramPacket(buf, buf.length, groupAddr,port);
    try{
        multicastSocket.send(sndPckt);
    } catch (IOException e) {
        /* Error handling. */
    }
/* RECEIVE METHOD EXAMPLE. */
    DatagramPacket recv = new DatagramPacket(buf, buf.length);
        try{
            multicastSocket.receive(recv);
        } catch (IOException e) {
            /* Error handling. */
        }

I've found this answer but it talks about using the sameDatagram Packet. I've also tested my application but I didn't found any race condition or inconsistency but I'm not 100% sure that there usage is thread-safe.

What does the documentation say about thread-safety of those methods? — Kayaman, Jan 15 '18 at 14:22
The documentation does not alway say everything, don't you think? — simo-r, Jan 15 '18 at 14:59
Sometimes the documentation says a lot when it says nothing. Other times, the opposite. — Kayaman, Jan 15 '18 at 15:00
That you're getting some grade A answers when both EJP and Stephen C are involved. Not to mention that they agree! — Kayaman, Jan 16 '18 at 09:26

Stephen C · Accepted Answer · 2018-01-16T01:31:14.093

The javadocs do not say whether or not MulticastSocket is thread-safe or not, but reading the sourcecode indicates that it is.

The joinGroup() and leaveGroup() methods are wrappers for native calls, which are (in turn) wrappers for system calls. All system calls are thread-safe, at least in respect to data held in kernel-space. (If they weren't, that would be a potential security flaw.) My reading of the code is that joinGroup() and leaveGroup() do not update any user-space data.
The send() and receive() methods synchronize on their DataPacket arguments to ensure that two threads using the same DataPacket can do so safely. Apart from the data packet objects, these methods don't update any shared socket state in user-space, and (as above) we can assume that kernel-space data is thread-safe.

EJP reasons that these syscalls are atomic (by design) and therefore thread-safe. That is correct¹. However, thread safety in user-space (i.e. before and after the syscalls, or when two syscalls share a user-space buffer) also needs to be considered.

^{1 - at least to my understanding. I couldn't find a definitive source which says which syscalls are atomic by design.}

Agreed. I was more concerned about reading my ancient Sun post into the record here. — user207421, Jan 15 '18 at 15:31

score 3 · Answer 2 · answered Jan 15 '18 at 14:52

Do I have to synchronize calls to joinGroup() and leaveGroup() methods?

No.

Do I have to synchronize calls to send() and receive() methods which uses always new istance of datagram packet as parameter?

No.

DatagramSocket reads and writes are independent of each other.
DatagramSocket writes are atomic at the OS level, so they are thread-safe.
DatagramSocket reads are synchronized by Java, and they are also atomic at the OS level, so again they are thread-safe.
MulticastSocket inherits its I/O methods from DatagramSocket.
joinGroup()/leaveGroup() are also atomic at the OS level.

Lest I am accused of plagiarism I will state that that link is itself an unauthorized copy of material I originally wrote on the Sun Java forums decades ago.

I suggest you get authorization from yourself before you post links to your content. — Jeffrey Blattman, Aug 09 '21 at 22:59

MulticastSocket join/leave group, send, receive thread-safety

2 Answers2