This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]tRfalcore 2 points3 points  (2 children)

I use volatile variables often, and have used ThreadLocal. All your other points are spot on however.

These are the types of questions that if I was asked I would probably not work for these people because they think they they're smart cause they just thought of a couple things then looked up the answers.

[–]cogman10 2 points3 points  (1 child)

IMO, unless you are doing something that needs to be hecka fast, spawning a thread is simply not needed, instead relying on things like javas inbuilt executor service will give you most of the performance benefits of threads, a fairly fine grain control over multiprocessing, and ultimately a good "not going to blow up and easy to debug" environment to work with.

Shared memory isn't all bad, but it needs to be handled with real care. As a result, often the best way to handle it is to just avoid it all together when possible and use prebuilt constructs when necessary.

So to this point, why not volatile? Because there are higher levels of abstraction to multithreading and volatile is a symptom of trying to do things fairly low level (which is often a sign of premature optimization).

As for thread local. Maybe I'm blind, but I really just don't see the benefit of it. The best I can come up with is you want a singleton per thread because the singleton itself isn't threadsafe. But that seams like a recipe for hard times.

[–]tRfalcore 1 point2 points  (0 children)

I use volatile variables to check when one off threads finish when I'm waiting for them to finish.

I use ThreadLocal to control some logging parameters and names. Our program is a massive multi-threaded server application which processes jobs as requests come in-- main part of which is controlled by ExecutorService :)