Is this custom interface implementation threadsafe

Question

I have many threads using the below interface ServerMessage

If many threads call the dataChanged() at the same time im
using the SwingUtilities.invokeLater to fire of the job.

My feeling was that this would hold but could not more then
one thread enter the dataChanged() and reassign the runnable before the SwingUtilities.invokeLater(runnable); is processed?

Maybe i should put a lock on the runnable like this.

  synchronized (runnable) {
    work...
  }

And what about the sO wouldn't that one also change when next thread enter?

My interface used by many threads

public interface ServerMessage{

    public void dataChanged(ServerEventObjects se);

    public void logChanged(String txt);

}

This is the interface method

@Override
public void dataChanged(final ServerEventObjects sO) {

 Runnable  runnable = new Runnable() {

    public void run(){

    // create new ServerEventObject to avoid making changes to original.
    // could clone() it but mongoDb didn't like that
        ServerEventObject serverEventObject = new ServerEventObject();

        serverEventObject.eventUuid = sO.eventUuid;
        serverEventObject.eventUuid = sO.message;

        jTextAreaLog.append(serverEventObject.message +"\n" );

        JTableModel.add(serverEventObject)

   }
 };
 SwingUtilities.invokeLater(runnable);
}

Me being picky; Your title is a bit misleading. Interfaces don't have thread safety issues, implementation of those interfaces can though. — Andrew White, Mar 31 '12 at 22:31
@AndrewWhite, not the whole story. For example, if a method .delete(key) must be called with valid key checked with .isValid(key) there is no thread safe way to implement the interface in case keys can be invalidated from other threads. If there is no possible/reasonable implementation of an interface, the interface itself can be called thread unsafe. — Johan Lundberg, Dec 12 '13 at 14:32
@JohanLundberg Interfaces are not for expressing conditions such as `methodA` must be called before `methodB`. If a particular implementation requires such things then the implementations has the thread safety issue, not the interface. — Andrew White, Dec 12 '13 at 16:59
@AndrewWhite. If we don't have the same interpretation of the word interface so be it. Instead of repeating my argument, those interested in interface and implementation design suitable for concurrency could have a look at C++ Concurrency in Action: Practical Multithreading by Anthony Williams. It's focusing on C++ but the issues are almost identical. — Johan Lundberg, Dec 14 '13 at 10:34

Edwin Dalorzo · Answer 1 · 2012-03-31T22:52:40.633

Thread-safety is an issue that derives from sharing the state of a given object between different threads.

Interfaces have no implmentation and therefore they do not have safety issues. On the other hand, your classes implementing these interfaces, and depending on usage, may need to deal with thread-safety issues.

Is your method modifying any state in delcaring class?
Is your method modifying the sate on any other objects shared with other threads?

In the code that you shared, there is no shared state between threads that is being compromised.

Since you are using invokeLater() you are making sure that any changes made to Swing components are done through the EventDispatch thread controlled by Swing.

We could argue that the object that you receive in the method as parameter is also compromised, but since you do not change its state, then for the time being it is safe.

So, it appears your code is thread safe.

was thinking for a second that there was only one dateChanged(). — Erik, Mar 31 '12 at 22:38
@Erik, the thread-safety issues would be in the class where you declare the method `dateChanged` if it changed the state of its object (which does not appear to happen in your code) or if you changed the state of the ServerObjects parameter that you recieve in the method (but that does not happen either), or if it changed the state of Swing components outside the `EventDispatchThread` which does not happen either. — Edwin Dalorzo, Mar 31 '12 at 22:43

score 1 · Accepted Answer · edited Jun 20 '20 at 09:12

1

My feeling was that this would hold but could not more then one thread enter the dataChanged() and reassign the runnable before the SwingUtilities.invokeLater(runnable); is processed?

There is nothing shared between the threads that would allow this kind of behavior. Inside dataChanged you create a new Runnable instance and every thread that invokes the method would do the same. Given your code, no thread would be able to modify the same Runnable instance since none of the threads share the same instance.

In other words: your implementation of the given interface is thread safe.

Update

I think a good article to read on the topic is The Architecture of the Java Virtual Machine. Since each thread has its own stack, the method invocation, including any local variables, calculations and return values (if any), will be pushed on the calling thread's stack. Since thread stacks are not shared, then no other thread will be able to "see" the local variables. The only way a thread can "interfere" with each other is if they share something and in this case they're not sharing anything.

edited Jun 20 '20 at 09:12

Community

1
1

answered Mar 31 '12 at 22:31

Kiril

39,672
31
167
226

So the dateChanged() method is running on the thread that calls dateChanged()? – Erik Mar 31 '12 at 22:41
1

@Erik bah, typo... should be `dataChanged`. But yes, the `dataChanged` method is running on the thread that called it. – Kiril Mar 31 '12 at 22:46
@Erik to be more precise: the method itself is not a shared piece of memory. – Kiril Mar 31 '12 at 22:50
thanks for clearing this up, wrote this code some time ago after reading about interfaces. interfaces takes some getting use to – Erik Mar 31 '12 at 23:06

score 1 · Answer 3 · answered Mar 31 '12 at 22:31

1

This particular method is thread safe.

Because runnable is a local variable, each such thread will allocate its own independent runnable. No reassignment can therefore happen.

And if you ask, jTextArea.append is thread safe, although most of Swing is not.

answered Mar 31 '12 at 22:31

Jirka Hanika

13,301
3
46
75

1

In Java 7, `append()` is no longer thread-safe, as mentioned [here](http://stackoverflow.com/a/3245805/230513). – trashgod Mar 31 '12 at 22:36

Is this custom interface implementation threadsafe

3 Answers3

Update