In the conclusion of his parallel programming series, David Chisnall looks at using threads. Threads are not a traditional way of achieving parallelism on UNIX platforms, but the newer POSIX standards come with a comprehensive set of functions to support them.
To read all comments associated with this story, please click here.
Member since:2006-11-28
Member since:2005-11-15
Member since:2006-02-15
Member since:2005-11-14
to those who know something about it.
and C programming, that too
You mean, not people like you then.
The very first example in this article returns a pointer to an item on the stack. It's the sort of subroutine we give to potential interns as part of the interview process. "Can you see the mistake?" We don't hire interns who don't
No, it doesn't, it returns a pointer to an item on the heap. So obviously you avoid all the good programmers out there, and keep the bad ones. Good job !
Chisnell claims that threads make programs more difficult to debug
They are. Concurrency brings all kind of problems. Shouldn't be news to you if you really took classes in this domain (which was my favorite). Perhaps you're a genius though.
they were in a camp that found threaded programming for UI based code easier and more bug free then the then-popular event model
But ... the event model use threads too. But they avoid them like the plague. And rightly so. Nearly every code with threads had race conditions.
Member since:2006-02-15
they were in a camp that found threaded programming for UI based code easier and more bug free then the then-popular event model
But ... the event model use threads too. But they avoid them like the plague. And rightly so. Nearly every code with threads had race conditions.
When you comment on a historical observation, it is nice to comment on the actual history.
The then-popular event model (circa 1985) did not expose threads to the programmer and its concurrency was often implemented without any threads at all.
Garret Schwart (sp? -- it's been a long time) brought the first thread proposal to the Posix committee and argued the advantage of threads over events for programming UI code.
Member since:2005-07-06
The very first example in this article returns a pointer to an item on the stack. It's the sort of subroutine we give to potential interns as part of the interview process.
What happens when the intern points out that you are using calloc, and it is actually heap allocated?
they were in a camp that found threaded programming for UI based code easier and more bug free then the then-popular event model.
Well, what exactly is an event model? It covers a wide area, and it actually uses threads. The only caveat is that you want to keep that thread use down to an absolute minimum, because the last thing you want are lots of awful race conditions in user interface based code that you'll have to try and debug.
User interface programming opens a can of worms in terms of the possibilities of things to go wrong, so I can't see thread based programming being more bug free there.
Edited 2007-01-22 12:36
Member since:2006-02-15
The very first example in this article returns a pointer to an item on the stack. It's the sort of subroutine we give to potential interns as part of the interview process.
What happens when the intern points out that you are using calloc, and it is actually heap allocated?
I look around very sheepishly and then hand them the program I meant for them to look at.
Well, what exactly is an event model? It covers a wide area, and it actually uses threads. The only caveat is that you want to keep that thread use down to an absolute minimum, because the last thing you want are lots of awful race conditions in user interface based code that you'll have to try and debug.
The then-current event model was much simpler. It was often implemented without threads. The underlying system used interrupt service routines to serialize i/o events (and thus the name 'event model') and place them on a queue from which they were removed by the 'event handler' and processed one at a time.
Member since:2005-07-09
Member since:2006-01-16
Member since:2006-02-15
Member since:
2006-02-15
to those who know something about it.
and C programming, that too.
The very first example in this article returns a pointer to an item on the stack. It's the sort of subroutine we give to potential interns as part of the interview process. "Can you see the mistake?" We don't hire interns who don't.
Chisnell claims that threads make programs more difficult to debug. While this is true for the way most people write code (especially those who return pointers to items on the stack) on a historical note, the orignators of the proposal that became pthreads brought the proposal to us at POSIX because they were in a camp that found threaded programming for UI based code easier and more bug free then the then-popular event model.
Edited 2007-01-22 08:17