Office Hours — Today, June 22

← Tuesday, June 20

Jun 22
7:25 PM
Mark M.
has entered the room
Mark M.
turned on guest access
Steve S.
has entered the room
Mark M.
hello, Steve!
how can I help you today?
Steve S.
Hi, Mark!
Let me paste in my question:
View paste (6 more lines) 
I'm working on some Bluetooth code that spawns threads and am trying to get the concurrency correct. One question I have concerns accessing a field in a Thread subclass from both the constructor and the run() method. My understanding is that the constructor and run() execute in different threads. So I'm wondering if it would be correct to make the field volatile, as follows:

class ReadThread extends Thread {
	final volatile private BluetoothSocket mmSocket;
	
	ReadThread(BluetoothSocket sock) {
		mmSocket = sock;
	}

	@Override
	public void run() {
		InputStream is = null;
		try {
			is = mmSocket.getInputStream();
		} catch (IOException e) {
...
Mark M.
well, the constructor will have completed before run() gets called
Steve S.
ok
Mark M.
so, that particular bit of contention can't happen
Steve S.
Right. But isn't there a separate issue about visibility?
Mark M.
um, well, it's private
nothing other than ReadThread can get to mmSocket
now, if you have other methods on ReadThread, and those methods might be called on some thread other than then the "real" thread that run() is called on, *then* you could have an issue
though I doubt volatile is sufficient in that case anyway
if you want to have the field be volatile, that's fine -- I don't think it is causing any problems here
but I'm not sure that it's giving you any benefits, either
Steve S.
Right. But I thought that if a variable is accessed from two different threads , changes made in one thread won't necessarily be visible from another thread.
7:30 PM
Mark M.
only if that code is happening at the same time
and even then, the story gets complicated
in this case, the constructor completes before run() executes
run() will see whatever the constructor assigned to mmSocket
Steve S.
That's the part I'm not sure about.
Mark M.
:: shrug ::
I have never had a problem with it
but, again, if volatile makes you feel better, keep it
Steve S.
For instance, in Effective Java in the chapter on Concurrency, it says that "Without synchronization, one thread's changes might not be visible to other threads." My understanding is that the variable could be cached, so it would be visible to the thread in which it's set, but not other threads.
Mark M.
again, that is for *parallel work*
again, the constructor will complete before run() is called
Steve S.
ok. So as long as what's done in one thread completes before what's done in another thread, visibility isn't a concern?
Mark M.
correct
Steve S.
ok
7:35 PM
Steve S.
Another question: I'm putting the Bluetooth code in a service. I have some running threads that I shut down in onDestroy(). I know that onDestroy() won't always be called, for instance, if there's a low memory situation. But in that situation, would those threads be shut down?
Mark M.
in that situation, the process is terminated
in which case, the threads, the Bluetooth connection, and all your objects, go *poof*
Steve S.
Ok. So if onDestroy() is called, I need to do something to shut down the threads. But if onDestroy() isn't called, I don't need to do anything?
Mark M.
there are three possible scenarios:
1. onDestroy() is called
2. the process is terminated, in which case, there is nothing that you can do anyway
3. you crashed with an unhandled exception, in which case you are dealing with matters in some UncaughtExceptionHandler (e.g., using ACRA for crash logging)
#3 can be a slightly sticky wicket
but, of course, your code will never crash, right? :-)
Steve S.
of course not!
ok. I think I understand.
Very helpful answer. Thank you so much! No more questions today.
7:40 PM
Mark M.
happy to be useful!
Steve S.
Have a great rest of the day, Mark!
Mark M.
you too!
Steve S.
has left the room
8:25 PM
Mark M.
turned off guest access

← Tuesday, June 20

 

Office Hours

People in this transcript

  • Mark Murphy
  • Steve S