Multithread communication: how good is the use of Atomic Variables like AtomicInteger? why is there no AtomicFloat?

Question

Intro:

I want to create a multithreaded android app. My problem is the communication between the threads. I read about communication between threads and I came across stuff like Looper/Handler design, which seemed quite involved and Atomic Variables like AtomicInteger. For now, I used AtomicInteger as a communication but since I am not very experienced in Java, I am not sure if that is bad in my case/ if there is a better solution for my particular purpose. Also I got a little suspicious of my method, when I noticed I need actually something like AtomicFloat, but it's not existing. I felt like I am missusing the concept. I also found that you can make yourself an AtomicFloat, but I am just not sure if I am on the right way or if there is a better technique.

Question: Is it ok/good to use Atomic Variables and implement also AtomicFloat for my particular purpose (described below) or is there a better way of handling the communication?

Purpose/Architecture of the App using AtomicVariables so far:

I have 4 Threads with the following purpose:

1.SensorThread: Reads sensor data and saves the most recent values in AtomicVariables like

AtomicFloat gyro_z,AtomicFloat gyro_y, ...

2.CommunicationThread: Communication with the PC, interprets commands which come form the socket and set the state of the app in terms of a AtomicInteger: AtomicInteger state;

3.UIThread: Displays current sensor values from AtomicFloat gyro_z,AtomicFloat gyro_y,

4.ComputationThread: uses sensor values AtomicFloat gyro_z,AtomicFloat gyro_y, ... and state AtomicInteger state to perform calculation and send commands over USB.

Answer 1

You basically have a readers writers problem, with two readers and (for the moment) only one writer. If you just want to pass simple types between threads, an AtomicInteger or a similarly implemented AtomicFloat will be just fine.

However, a more accommodating solution, which would enable you to work with more complex data types would be a ReadWriteLock protecting the code where you read or write your object data:

e.g.:

private ReadWriteLock readWriteLock = new ReentrantReadWriteLock(); //the reentrant impl

....

public void readMethod() {

    readWriteLock.readLock().lock();

    try {
        //code that simply _reads_ your object
    } finally {
        readWriteLock.readLock().unlock();
    }

}

public void writeMethod() {

     readWriteLock.writeLock().lock();

     try {
        //... code that modifies your shared object / objects
     } finally {
         readWriteLock.writeLock().unlock();
     }
}

This will only enable "one writer-only" or "multiple reader" scenarios for access to your shared objects.

This would enable you for example to work with a complex type that looks like this:

public class SensorRead {

    public java.util.Date dateTimeForSample;

    public float value;

}

While using this data type you should care if the two fields are set and modified safely and atomically. The AtomicXXX type objects are not useful anymore.