Running a multithread application

Question

I have got my self really confused while making a chat application. This is where my problem is. I have many classes in the application. One of them is responsible for the communication so its sending and receiving messages(receiving is done through a second thread invoking the receive method when a message comes much like observer pattern). What I can't figure out is what will happen if a message is received at the same time the application is trying to send a message. Will the application run normally because receive is called from another thread?

Thanks

ps: I am still on design phase thats why I don't just test it.

Answer 1

As the saying goes, the devil is in the details. In this case, the details are the variables that are accessible to the code running in different threads. With multi-threaded applications, the same method—even the same line of code—can be running under two threads at the same time. A big issue here is race conditions: a variable (or set of variables) is being changed by one thread while another thread is reading the variable(s) under the assumption that the data are stable. This is usually dealt with in Java by using synchronized blocks—a form of locking. (There are other mechanisms as well, such as volatile or atomic data structures.) But this opens up a second danger: deadlock. In the simplest case, this is where two threads need to synchronize on multiple resources and each thread is waiting to lock on a resource that the other thread has already locked. The simplest way to avoid deadlock is to either never lock on more than one resource or to acquire locks in the same relative order on all threads. More details about all this can be found in the Java tutorial Processes and Threads.

I like to anthropomorphise threads: think of each thread as a separate worker sitting around the table. Each worker has a pile of private papers but occasionally does something with a shared pile of papers in the center of the table. (In code, there usually is no such thing as "the center"—although some designs do create a separate class that encapsulates the shared data.) A worker can put a note in the center, addressed to one of the other workers, asking that specific work be carried out; the receiving worker may then deliver results back to the center addressed to another worker. Other than the shared data at the center of the table, the workers act independently. (Synchronization involves gathering together certain papers in the center and temporarily putting them in a box labeled "reserved for XYZ". No worker other than XYZ can access a paper as long as it is reserved for XYZ.) Note that the only area of contention among multiple workers is the shared data at the center of the table.

For your particular application, it sounds like you need at least three threads: one that manages the user interface; one that sends messages; and one that receives messages. The main thread (the one that contains the code that the system calls to start your application) should be the UI thread and it should start the other two threads. There are obviously going to be interactions between the UI thread and each of the other two. It's not clear at all if there needs to be any interaction between the sending and receiving threads; it might be very easy to design them to operate with no (modifiable) data in common.

At the very abstract level at which you describe your design, I don't think it has any inherent problems. I recommend that you go ahead with coding, keeping in mind the issues of shared data access and synchronization. You can always ask for help if you run up against specific problems.

Answer 2

Are you familiar with java.util.concurrent?

If not, you should go and learn it before writing any more code. It will have tools in it which will help you.