CODEWITHSUNDEEP
javamultithreadingthread-safetymulticast
simo-r
simo-r

Reputation: 733

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

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:

  1. Do I have to synchronize calls to joinGroup() and leaveGroup() methods?
  2. 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.

Upvotes: 0

Views: 1297

Answers (2)

Stephen C
Stephen C

Reputation: 718708

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

  1. 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.

  2. 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 correct1. 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.

Upvotes: 3

user207421
user207421

Reputation: 310860

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.

Upvotes: 3

Related Questions