2

I want to use some mutable vars defined in a thread MyT which extends Java's Thread in application and the usage will be as Thread.currentThread.asInstanceof[MyT] to reference and update mutable vars in it.

Will this be thread-safe?

update

I wrote some application using scala without any consideration of multi-thread issues and with the so-called worst practice of using mutable variables in object (because it is so easy to use for beginners!).

But now somehow the project extends to a web application, that I have to deal with multi-threading issues.

I dont have time to rewrite the code again, to refactor every mutable vars in object as arguments around (probably one solution of not using global object mutable vars), so I am thinking about moving the mutable vars in object to a thread class that extends Thread class, and refactor the code to use Thread.currentThread and then cast the instance to my extends thread type, and then to reference/update to the mutable vars which are originally global mutable vars.

So here comes my original question.

monica
  • 1,035
  • 1
  • 9
  • 21
  • Can you elaborate more? – Jaydeep Rajput Apr 10 '13 at 05:03
  • 1
    Adding thread safety as an afterthought is never going to be ideal. You would be better to take the time to redesign. – Roger Rowland Apr 10 '13 at 05:08
  • @RogerRowland Then why gcc support the `thread_local` keyword recently?! – monica Apr 10 '13 at 05:26
  • 2
    @monica, Thread local is not a silver bullet which magically resolves all problems with concurrency and thread safety. It is just another instrument, just like mutexes, locks, thread pools etc. It has its own applications. For example, thread local variables are useless when you want to share some data between threads (obviously, 'thread *local*' name suggests it). If you want to exchange data between threads, you should use locks and other concurrency primitives. Thread locals are rather a convenient safety measure when you *do not want* to share the data between threads. – Vladimir Matveev Apr 10 '13 at 05:42
  • 1
    See here: http://stackoverflow.com/questions/1490919/purpose-of-threadlocal – Vladimir Matveev Apr 10 '13 at 05:43

3 Answers3

5

Use ThreadLocal for this purpose : http://java.dzone.com/articles/java-thread-local-%E2%80%93-how-use

Martin V.
  • 3,560
  • 6
  • 31
  • 47
2

If you only interact with the mutable variables from within the thread itself (the Thread.currentThread.asInstanceof[MyT] use case you mentioned), then it is thread safe (and usually faster than ThreadLocal).

If you interact with the variables from any other thread, then it is likely to not be thread safe.

Of course, it's still not very Scala-ish. You should try to avoid mutable state wherever you can. If you've got some code that looks hard to refactor, the good people of Stack Overflow are always keen to help.

James_pic
  • 3,240
  • 19
  • 24
  • Nice!! Thanks for the confirmation of my use case! (yeah, I only needs to interact with mutable vars within a thread (fortunately). and yes, after you guys' suggestion, comment and suggestions, I do realize I should do serious design and practice first, rather than "afterthoughts" like this. – monica Apr 10 '13 at 21:11
2

The native scala solution is to use scala.util.DynamicVariable[T]. E.g.:

import scala.util._

class TL {
  var x = 0
}

object TL extends DynamicVariable[TL](null) {
  def apply() = value
  def initialize { value = new TL }
}

class Counter(val limit: Int) extends Runnable {
  def run {
    TL.initialize
    for (i <- 1 to limit) { TL().x += 1 }
    println(TL().x)
  }
}

object Program extends App {
  val t1 = new Thread( new Counter(1000000000) )
  val t2 = new Thread( new Counter(2000000000) )
  t1.start; t2.start; t1.join; t2.join
}

Internally, DynamicVariable uses java.lang.InheritableThreadLocal.

Reimer Behrends
  • 8,600
  • 15
  • 19