12

Implementing threading in a program is hard, yes, however why is it that some people will not implement them even when there is an obvious need for it.

An example: Program has to load a dataset from a database, the thing to do would be to make the connection and get the data from the database in a worker thread and then load it into the GUI, leaving the GUI thread responsive for the user.

But no, I've talked to people whom seem to think that threads are evil and bad and whatnot and one should avoid them at all costs. I've even heard that some class instructor advised against to use of threads and therefore did not want cover their use. WHAT???

With the hardware going into multi-core, I think that we need to understand threads better and not be afraid to use them. I find it a fascinating subject personally.

So what are things you've heard about threading that are false?

Tony The Lion
  • 395
  • Misfits and underachievers cannot handle threads. The real question is: what are you going to do about that? – Job Feb 03 '12 at 20:44
  • 3
    Those are not false ideas, but threads should always be avoided. Do your architecture correctly so that the threading support has already been correctly handled and every programmer do not need to do it themselves. Once programmers learn to add a thread every situation you'll have a big problems. – tp1 Feb 03 '12 at 20:53
  • Let me turn the question back around on you. Have you asked yourself whether there are alternative approaches to exploiting parallel processing capabilities? Or, did you just jump straight to threading because some whitepaper said to, or maybe because that's what better programmers seemed to think was cool? Personally, I like the idea of lightweight processes passing messages to each other much better than threads. Am I lazy / stupid / in a hurry? Yeah- and so are all of us, to various extents. – user1172763 Aug 22 '14 at 15:55

7 Answers7

19

Threading is hard

Sure. It can be. However, people get this idea in their head that it's so hard, such that they don't bother trying to figure it out.

It's not like it's impossible.

Steven Evers
  • 28,180
  • 2
    I support this answer. People think it's hard. However it's not when you spend enough time trying to understand. –  Dec 22 '10 at 07:30
  • 11
    @Pierre, I would expect that lots of people's definition of hard is "you have to spend enough time trying to understand". – Benjol Dec 22 '10 at 10:16
  • 1
    Threading is getting to be a lot easier with TPL and await/async keywords :) – Rachel Feb 03 '12 at 20:27
  • @Pierre 303: When you spend enough time to understand it's still hard, and in fact the people who understand it best are the most likely to avoid it as much as possible. – Michael Borgwardt Aug 31 '12 at 12:26
9

It's not the threading part that's hard but the need for synchronization and everything else that comes with using threads. In your GUI example how do you tell the main thread the dataset is ready to be accessed? Do you pass around a whole bunch of callbacks? Do you scatter a whole bunch of check variables throughout your code? In some GUI models, e.g. Silverlight, there's something called thread affinity which means you don't get to access GUI elements sitting on the main thread from other threads so you have to get out of your way to let the main thread know certain information is ready to be processed further.

I haven't really heard any false things about threads. I've just read a whole bunch of situational case studies about synchronization being a bitch when whatever algorithm you are using isn't inherently parallel.

3

Threading solves all your problems

If you're having performance issues you should not jump right to threading.

Threads are lightweight

Threads are lightweight in tens and twenties. Spawning thousands of threads is not.

Threading is easy [Java]

It's easy to create threads, that doesn't mean you will benefit from it.

Josh K
  • 23,029
  • Just for the record, Mac OS won't let you (on a default install) create more than 512 threads. – zneak Dec 21 '10 at 23:36
  • 1
    That really depends on your language. Spawning 1 million threads in Erlang is barely noticeable, even on an older laptop, let alone a modern server. And actually, these aren't even just threads, they are full-blown processes, i.e. much heavier than threads. In addition to their own program counter and call stack (which are pretty much the only things a thread has), they also have their own heap and even their own garbage collector. – Jörg W Mittag Dec 22 '10 at 01:31
  • 4
    @Jörg W Mittag: I am confused by your comment. How does erlang change how the OS creates a thread or process? – Steven Evers Dec 22 '10 at 06:47
  • 1
    @SnOrfus: Erlang doesn't use OS threads. There are three main Erlang implementations right now: BEAM, HiPE and Erjang. BEAM and HiPE are native implementations (that can even run without any OS at all) and implement their own processes. Erjang runs on the JVM and implements processes using the fantastically brilliant Kilim library. – Jörg W Mittag Dec 22 '10 at 13:35
  • @Jörg W Mittag: Considering my question http://programmers.stackexchange.com/questions/28453/what-3-4-languages-provide-the-best-variety-in-style, I find this very interesting. Thank you. – Steven Evers Dec 23 '10 at 04:44
1

An example: Program has to load a dataset from a database, the thing to do would be to make the connection and get the data from the database in a worker thread and then load it into the GUI, leaving the GUI thread responsive for the user.

I don't see that this situation represents a necessity to use threading for at least 4 reasons:

  1. The data retrieval should be very fast.

  2. In many Line of Business applications, the user has nothing to do with the application in the 1 second or two he/she is waiting for the result. Also, the user will have to wait until the data comes back any way to complete the desired task. The query on the other hand could be coded intelligently such that it retrieves only a page-full of information at a time and other optimization techniques could help the response time.

  3. In web based interfaces, links may be made active regarding of the threading model.

  4. Threading adds complexity as you admit, some developers down the line may not be able to add features or debug complex code.

My opinion is: Use threading when you must because software maintainability and reliability is more valuable to an organization than code elegance.

NoChance
  • 12,462
  • 1
    Your first point reminds me of the fallacies of distributed computing ( http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing ). An awful lot of users may begin to wildly click around when they have to wait more than 1 or 2 seconds from your point 2 for an unresponsive interface, making things worse. – Secure Feb 04 '12 at 08:03
  • @Secure, the link is interesting, thanks for sharing it. I am not sure we could ever capture the user's focus all the time on interface or even on the entire job in this day and age. I agree with you that in E-Business sites, you don't want the user to go away at all. – NoChance Feb 04 '12 at 10:30
  • I'm not talking about the focus. When the user clicks on a button and the interface just freezes because the database is queried, without some visual response that something is done, some users try to click the button again. And again. Then try to click other buttons or options. I've seen admins doing this who should know better. – Secure Feb 05 '12 at 06:42
  • Even worse when the result screen is first drawn, but shown empty. Don't know about most current versions, but the search result in older Outlooks is a good bad example. When starting the search, it shows "Result set is empty" or something like this, for some seconds with a large search base, showing the first results when found. If you're too impatient or in a hurry, you've already switched to the next folder, believing that nothing's there. – Secure Feb 05 '12 at 06:46
  • 1
    @Secure, I see your point. What you are describing here shows a good example of an inconsistent user interface. What you have described also occurs when you search for files. But what is the answer to this other than telling the user that the search has already begun? – NoChance Feb 05 '12 at 07:04
1

If you don't want to write tests for your code, then don't use threads.

Threads are not for the typical 'copy and paste' programmer who does not understand underlying fundamentals of OS and computer architecture. Since 90% of programmers are only familiar with Java, these really are not the people who should be using threads. Java makes threads "easy" but I've seen a lot of programmers who just think that if they used synchronized structures their code will work in threads .... uhm no.

That being said, everyone needs to start somewhere, just don't make your first threading project upgrading your companies production backend server.

cmcginty
  • 729
  • Can you recommend some resources on how to do threads correctly? – Jonathan Feb 02 '12 at 15:23
  • I'm sure this has been addressed. Try starting here http://stackoverflow.com/questions/660621/threading-best-practices – cmcginty Feb 03 '12 at 20:18
  • The problem with this is that even if you have 100% test coverage you will have no way of knowing if your tests will cover all possible issues with how instructions interleave with shared resources. On the other hand with a shared nothing architecture it becomes much easier. – Zachary K Apr 20 '12 at 12:22
1

You will eventually loose any gains from threading because fixing crazy bugs that will arise from use of some libraries/functions that are not thread safe (what you were not aware of) will require excessive synchronization.

You have much higher probability of encountering bug that you will not be able to fix if you use threads then when you don't.

Kamil Szot
  • 144
  • Unfixable bugs? I've not seen one of those before.. – adamk Dec 22 '10 at 15:44
  • You really have never seen a bug that you could not fix? In the time and for the pay that was available? – Kamil Szot Dec 22 '10 at 22:31
  • If you've never encountered an unfixable bug then you haven't been in the industry long enough. In my 12+ years working, every project I've ever looked at has at least one bug that nobody has fixed and nobody knows how to fix or even reproduce. This includes code I've been employed to work on and code I have access to read (open source code). The only pieces of software that's bug free are ones that's less than 2 or 3 pages long. But making all your code 1 or 2 pages long doesn't fully solve anything because then you have integration bugs. – slebetman Aug 23 '14 at 09:05
1

To summarize point wise why threads are difficult to use :-
True Things 1) Need the synchronization, and careful design decisions about what to lock and when to lock
2) No control on the run time flow
3) Difficult debugging
4) (Very few times) platform compatibility :- Libraries do exists to take care of this

False Things : -
1) Confusing concepts of thread-safe and re-entrant functions
2) Threads looks good on the paper but are very hard to implement

Manoj R
  • 4,076
  • Are these supposed to be true or untrue? The OP asked about what things that are not true, and scare people away from doing multi-threaded programming. – Steven Evers Dec 22 '10 at 06:41
  • actually you don't need locks or synchronization. There are also message passing models (e.g. erlang, scala), and STM models (e.g. clojure). And on top of that there are thread safe data structures that don't need locks (ConcurrentHashMap in java) and atomic primitives that don't require locks. – Kevin Feb 03 '12 at 20:50