Fog Creek Software
Discussion Board




What % of developers work with threads?

Question is self describing

Anon
Tuesday, July 29, 2003

13.483%

Statistician
Tuesday, July 29, 2003

100%. Every program has at least one thread. Do I get a prize? ;-)

Seriously, I don't see any way to answer this question. You could ask how many people here have done multi-threaded programming and those of us that have could put our hands up.

John Topley (www.johntopley.com)
Tuesday, July 29, 2003

You could get various answers depending on whether or not you meant somebody knew what a thread was, had used it once in code, used it regularly, debugged multithreaded code regularly, or knew about threads but only chose to use them where necessary.

Better Than Being Unemployed...
Tuesday, July 29, 2003

debugged multithreaded code regularly

Anon
Tuesday, July 29, 2003

Almost all Java programmers.

No VB Programmers (don't know about VB.Net)

Not too many C/C++ programmers.

He-who-would-not-be-named
Tuesday, July 29, 2003

Thrice in the last 4 years (in VC++). Is that good enough a percentage???

The One You Loved (TOYL)
Tuesday, July 29, 2003

Played with it.

I never found the effort worth the gain in terms of performance / responsiveness in the kind of applications I do. (usually database + data entry/reporting  front end of some kind)

Geert-Jan Thomas
Tuesday, July 29, 2003

I've done some simple TCP/IP server stuff using a threaded model. SMTP, POP3 servers and such.

Patrik
Tuesday, July 29, 2003

There's a hump of "gee whiz, cool" that goes along with the first time you use threads. Then, with maturity, you discover that threading really isn't the savior of the human race, and can easily introduce as many problems as it's purported to solve.

Tread lightly, young padawan.

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, July 29, 2003

Actually it can be done in VB, it's just not recommended and very scary.  See the Appleman debates at Desaware.

John Aitken
Tuesday, July 29, 2003

A set of course notes from some years ago gave the following advice :

"Writing multi threaded applications is more fun than writing single threaded applications."

"Debugging multi threaded applications is less fun than debugging single threaded applications."

To which I'd add the following :

"Debugging an application that is, at first glance, single threaded but in fact uses multiple threads inside a third party tool, and acts off events fired by it, is even less fun than debugging multi threaded applications."

Better Than Being Unemployed...
Tuesday, July 29, 2003

I've done a lot of multi-threaded work.  (Server-side and distributed computing stuff in Java.)  Enough that it's second nature to me to think in terms of multiple threads accessing the code I'm writing.

I'd say writing multi-threaded code (in Java) is twice as difficult/complex as writing single-threaded code.  Debugging a problem that is caused by a multi-threading issue (deadlock, etc.) is five to ten times harder.

-Thomas

Thomas
Tuesday, July 29, 2003

Threads are necessary if you want to provide a responsive user interface in an application that needs to perform lengthy operations. Such as:

- Network (upload / download)
- Calculations
- Compression

Without threads, it's very difficult to get a responsive user interface. You have to call back from the network/calculation code to process UI messages, deal with reentrancy problems, etc. Threads are a much better way to deal with this IF you are experienced enough to handle the concurrency and locking issues correctly.

Another area where multiple threads are frequently used is in servers that need to handle concurrent requests.

On the other hand, when threads were first introduced people often tried to use them to separate program logic, for example to use a different thread for each child window in an MDI application. That is a bad idea and is probably the reason that many people here are warning against threads.

I've used threads in almost all non-trivial applications that I've written.

Frederik Slijkerman
Tuesday, July 29, 2003

Whilst I would agree with your use of threads in applications for performing background tasks, I'd say there is a considerable difference between software that has to create one extra thread, and software that has to create many (such as, say, a server accepting remote requests from many clients). The latter can be exponentially harder to debug.

Better Than Being Unemployed...
Tuesday, July 29, 2003

Very rarely used them.  In general anyone thinking about using them I tell not to. 

Unless you really have a very good use for them it is unlikely that the benefits will outweigh the pain and frustration as you find that the books didn't document all the tricky little holes, or that you simply failed to realise their significance when reading about them.

Colin Newell
Tuesday, July 29, 2003

Let me also provide a little performance advice, if your target platform is Windows.

Processes in Win32 are address space dividers; threads are units of scheduling. It is equally costly to schedule a different thread in the same process as it is to schedule a different thread in a different process.

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, July 29, 2003

Anon,

Are you asking how many work with threads, or how many work with multiple processes/tasks/whatever where you can run into concurrency and contention issues?

IIRC, threads are light weight and you can have many per process, they share that process's context space? Where-as each process/task/whatever gets its own stack and address space? Someone please correct my terminology if I got it wrong.

I'm going to extrapolate from my own experience and say that most embedded developers work with processes/tasks/whatever without the benefit of virtual memory, so it's very similiar to working with threads. If that counts, then I'm going to guess 60% since most development jobs are embedded (or so I hear).

JbR
Tuesday, July 29, 2003

Threads are for programmers who don't know how to write state machines.

runtime
Tuesday, July 29, 2003

I use them all the time - I don't remember the last project I worked on that wasn't multi-threaded.  I checked in a fix for a race condition bug this morning (I didn't write the bug).  In C++, it's not too bad if the app is multithreaded from the start, but it's tricky if you're trying to add thread safety to existing code.  In java, just write all of your code with the correct synchronized sections all of the time, and you'll be ok.

Brian
Tuesday, July 29, 2003

State machines are for programmers who can't write threads.

Alyosha`
Tuesday, July 29, 2003

I've used them a lot in both C++ and java for applications that must receive input from multiple sources and carry out time sensitive tasks.

I'm a big fan of the KISS theory of design.  Don't use them unless you need to.  They are challenging to debug, and when there are bugs they often aren't consistently repeatable.  If the language you're working with has thread-specific keywords (volatile, synchronized, etc...) make sure you understand how they should be used.

That said, I really enjoy working with multithreaded code.  Works out well; most of the people I work with hate it passionately. ;)  I've got several years of classical music training and working with multithreaded code is more like composing something with multiple melodic and harmonic lines than anything else I can think of.

-K
Tuesday, July 29, 2003

[Threads are for programmers who don't know how to write state machines.]

Good lord, I hope that was a troll.  I'd much rather have this board infested with occasional trolls (easily deleted) than extremely ill-informed posters.

Anyway, for many, many problems, threads are the most reasonable solution.  And really people, they aren't that hard.  I'd seriously question the programming skill of any programmer who got confused by threads.  Making the occasional mistake with them (mutex in the wrong spot, using a single threaded lib call, etc.) is understandable, but claiming that you flat out shouldn't use them is simply baffling.

David
Tuesday, July 29, 2003

What does it mean to "work with threads?"

I do Java, so I need to use threads all the time in order for my GUI to appear responsive. Is that some big trick? Do I get a cookie now?

In PHP I never use threads, for some reason.

What motivated you to ask this question?

Nimoy's Bilbo
Tuesday, July 29, 2003

"State machines are for programmers who can't write threads."

Am I suppose to following this misconception with another misconception? How about this then, "Programmers are people who can't architect working commercial operating systems."... a statement like this is just as untrue. Many folks who code day in day out (knowing threads or state machines) can be dragged into Microsoft or Sun to write a few components of the next operating system or framework. Just because you use state machines doesn't mean you don't know threads, most programmers I know knows both just fine (or care too little about both).

Li-fan Chen
Tuesday, July 29, 2003

While the percentage cannot be resolved asking on a forum like this, I will still answer, "More than there should be."

It's difficult and requires either a lot of discipline or a lot of help from a framework. Most programmers don't normally summon that much discipline to get other work done; one cannot write such code casually. Design flaws and saftey errors are not easy to see in the surface syntax. One must have a clear, animated mental model that can be replayed and validated step-wise against the code.

The comments on state machines are insightful, curt as they are. Complexity latent in concurrency swings between state machines and cooperating threads. The former requires explicit context switches, forcing operations to be asynchronous; the latter hides the state suspension but makes data protection explicit. Comparing complexity in state management versus data isolation and exchange can determine which way and how far to lean.

Steven E. Harris
Tuesday, July 29, 2003

>>>
IIRC, threads are light weight and you can have many per process, they share that process's context space? Where-as each process/task/whatever gets its own stack and address space? Someone please correct my terminology if I got it wrong.
<<<

In Win32 at least, each process gets its own (virtual) address space: for example two processes can call "new" and both be given a pointer whose value is 0x100000, but dereferncing those pointers points to different bits of physical memory.

Note, however, that each thread within a process has its own stack, its own local variables (though every thread in the process shares the process' heap and global data segment).

Christopher Wells
Tuesday, July 29, 2003

I've been doing thread code lately.  This should help if your taking a hand count.  If your really going for a percentage....then i'm gonna say....66.43% ?

vince
Tuesday, July 29, 2003

"Good lord, I hope that was a troll.  I'd much rather have this board infested with occasional trolls (easily deleted) than extremely ill-informed posters."

I actually don't think it was a troll (although it was clearly designed to be decisive, something I thoroughly approve of :-p).

IIS on Windows achieves a SERIOUSLY high level of performance by using only a minimal amount of threading, and instead using what more or less amounts to asynchronous events and a state machine (a simplification of sorts, but not a big one). Having 1000 blocked and waiting threads is not really that great a thing when it comes to performance.

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, July 29, 2003

> What % of developers debugged multithreaded code regularly?

In C/C++ at least it can be pretty difficult to debug bugs that are caused by errors in a multithreading implementation: design and code inspections may be more effective than using test cases and a debugger.

Christopher Wells
Tuesday, July 29, 2003

By far, the most useful debugging tool is a multi-processor machine. :)

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, July 29, 2003

Contrary to common belief, it is much simpler to do network code with asynchronous code than it is with threads. Yes, the 10-liners based on threads are simpler; But a robust program based on threads is much more complex.

The "event driven" paradigm revolutionized interactive UI to the point that it's nearly impossible to find a sequential UI, and it happenned for a reason - they work better.

Async network works better for exactly the same reasons. Unfortunately, by the time writing network code became  common,  threads were widely available and common sense no longer is.

Ori Berger
Tuesday, July 29, 2003

P.S: The "computers are state machines. Threads are for people who can't program state machines" quote is credited to Alan Cox, as far as I know.

Ori Berger
Tuesday, July 29, 2003

"threads are for those who cannot write state machines"

then it would follow:

"an MMU is for people who can't handle flat memory"

Hello DOS, what a joy that was.

Bluto
Tuesday, July 29, 2003

"... instead using what more or less amounts to asynchronous events and a state machine (a simplification of sorts, but not a big one)."

You're going to block somewhere for something, whether its in your state machine or whether its in the thread scheduler - take your pick.  IIS people obviously decided they could do it better than their OS people.

Bluto
Tuesday, July 29, 2003

"You're going to block somewhere for something, whether its in your state machine or whether its in the thread scheduler - take your pick.  IIS people obviously decided they could do it better than their OS people."

Actually, no. They didn't choose "homebrew vs. OS feature", they chose "OS feature vs. OS feature" (namely, overlapped I/O vs. threads). In just about every discussion about performance, the topic of overlapped I/O comes up, and how it generally beats the pants off threading for I/O-bound applications (which IIS is).

If you don't know what overlapped I/O is, it's comparable to scatter/gather systems in Unix.

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, July 29, 2003

Brad -

"(namely, overlapped I/O vs. threads)"

Isn't it more complicated than that? I would have thought that IIS would use IO Completion Ports for its overlapped I/O and, well, that generally involves multi threading.

So I would expect that the design choice that they made was between IOCP and thread per connection. Assuming they did that then they would manage to scale nicely with a small number of threads handling a large number of active connections. But I've never seen the code for IIS ;)

People other than Brad -

If you don't know what IO Completion Ports are then take a look on MSDN or have a look at the articles I've written here:

http://www.jetbyte.com/portfolio-showarticle.asp?articleId=37&catId=1&subcatId=2

with some updated code for the articles here:

http://www.lenholgate.com/archives/000088.html

Oh, and to the original poster -

Yes, I use threads in C++ and C# quite a lot. Hopefully I use them when they're the appropriate tool for the job in hand.

Len Holgate
Wednesday, July 30, 2003



>  Processes in Win32 are address space dividers; threads are units of scheduling. It is equally costly to schedule a different thread in the same process as it is to schedule a different thread in a different
process.

Scheduling overhead maybe similar in Win32, but it is more costly to synchronize processes with Memory Mapped Files and Mutexes, compared to process local memory and Critical Sections of threads.

http://www.baus.net

christopher baus
Thursday, July 31, 2003

Christopher,

My point wasn't that there were NO differences. My point was to disuade people from believing that threads switches inside the same process were somehow magically super fast.

Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, July 31, 2003

Also, training your abs is certainly good for you but won't do much about your beer gut.  You've just got to eat less and maybe burn more calories by cardio training. :-)

Chris Nahr
Thursday, July 31, 2003

*  Recent Topics

*  Fog Creek Home