"I'm not back." - Bill Harding, Twister
Originally posted by Jim Yingst:
[Edward]: 1. do you think it is thread-safe ?
No, it isn't. There are several places where you have mutable data that is accessed by more than one thread with no protection. Specifically, the field AuthUser.user, and the fields User.userName and User.password. They are set in one thread and accessed in another. In theory the access "should" always happen after the initial setting - but this is the sort of thing where really weird stuff can happen with multithreading. It's not guaranteed.
For each of these fields, the basic options are: (a) synchronize access, or (b) make them immutable. In both cases I'd favor the second. For AuthUser.user, that's really simple - just declare it final. That, combined with being initialized in the constructor, is enough to guarantee that any other threads who see the AuthUser object will see it with its field properly initialized. For User.useName and User.password, you can do much the same thing, making both final. But then you have to change the class to ensure that both fields are set in the constructor, not after the constructor. If you don't want to do that, then you could instead synchronize each mehtod that accesses those fields. Or, you could also make both fields volatile it you like.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
"I'm not back." - Bill Harding, Twister
Originally posted by Jim Yingst:
No - user is definitely set by one thread (main) and read by a different thread (running AuthUser.run()). It does seem like the read will only come after the constructor completes, but it's not guaranteed because the JVM can do strange things with multiple threads.
"I'm not back." - Bill Harding, Twister
Originally posted by Jim Yingst:
but there are still two threads that use every object: main, and the new thread just created.
"I'm not back." - Bill Harding, Twister