Re: lines of code?
From: goose (ruse_at_webmail.co.za)
Date: 12/17/03
- Next message: Natasha: "include uploaded by a customer html to jsp"
- Previous message: Thomas Schodt: "Re: How many Internet Explorers have the Sun plug-in installed?"
- In reply to: Programmer Dude: "Re: lines of code?"
- Next in thread: Tim Ward: "Re: lines of code?"
- Reply: Tim Ward: "Re: lines of code?"
- Reply: Programmer Dude: "Re: lines of code?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 17 Dec 2003 06:58:25 -0800
Programmer Dude <Chris@Sonnack.com> wrote in message news:<3FDE00EF.FD87BB8F@Sonnack.com>...
> goose wrote:
>
> >> Anyway, I just wanted to toss one more "use of threads" into
> >> the hopper for you to shoot at.
> >
> > <grin> me to shoot at? full-time embedded developer, part-time
> > troll, is that What I've become ? :-)
>
> Nah. "Debate Partner" is the phrase. Trolling is something else
> entirely.
<grin> something to aspire to in my old age, then :-)
>
>
> >> Most browsers spawn threads to download the images of a page.
> >> That solution seems simpler to me than any involving interrupts
> >> or polling. One thread, one download.
> >
> > very good example. I'll conceded that that example really
> > is one that could benefit from a multithreaded design.
> >
> > (of course, a simple fork() system call could possibly
> > achieve the same result without using threads, but relying
> > on the OS to schedule your different tasks)
>
> Absolutely. My thought is that the threaded solution probably
> is easier to understand and maintain.
>
I suspect that it depends on your perspective as much
as the problem on hand. Elsethread, someone said something
about "... if computer science starts and ends with java ..."
The few times when I've had to work *with* (as opposed to
against :-) java developers, I've found that the first
/design/ decision being taken is to use threads. This is
possibly because from the perspective of a java-only or
java-mainly developer, its a foregone conclusion if you are
going to use java: threads are inevitable so one may as well
throw them into the design anyway.
My *major* gripe is that, in RealLife(tm) we programmer-types
do 90% maintenance, and 10% new development. Schools and
universities teach *only* how to write something from scratch.
Ok, Ok, there are the few "problems" along the lines of
"there is a bug in the following 30 lines of code, fix it", or
"what does the following code snippet do?". IMHO, this is
terribly unproductive, as very few development shops will
actually tell a programmer, "there is a bug in the next
30 lines of code". The programmer has to figure it out
on their own, *and* figure out /which/ 30 lines out of
a possible thousand.
Throw threads into this can of worms. Now the programmer
has to /also/ understand that some things are happening
/concurrently/, and that the bug they are hunting may
be one of those elusive creatures that *cant* happen
in a single-threaded application
(a show of hands, for all those who have found a race condition
in someone elses code after only a few weeks, I know I have:-).
IM_Even_More_HO, the teaching of computer science should be
just that: computer science. The current crop of new grads
that I sometimes have the misfortune to work with leaves
me almost weeping ... "a protocol stack? sure, lets do it
with Objects", "no need to draw a state-machine on paper,
we'll just create two threads to rx and tx".
And we wonder why software is so maintenance-intensive.
I sometimes think that teachers should be emphasising, at
the start of every lecture, "use the right tool for the right
job"; instead we get grads (here in SA, at any rate) whose
course curriculum /has/ included prolog(sp?), and C++, and
delphi, but who will tackle anything thrown their way with
java ("because thats what the industry uses most").
>
> > In my career, I've only once *needed* multiple threads for
> > my solution to a problem...
>
> I also have "needed" them only once. And there were surly other
^^^^^
They swear and curse at you, do they :-) ?
> designs available. Threads just seemed to make sense and be the
> easiest and most obvious.
yup. once again, it depends on the environment. if it seems to
be the "best fit", then it probably is.
(<sidenote> this is kinda like malloc() strategies. there's
best-fit and first-fit. I try to go the best-fit route
always, although the impression that I get from many programmers
is that they go the "first-fit" route. the first solution that
they think of is the one they would go with).
>
> App was a "controller" that launched and monitored other apps.
> It needed to be able to kill the launched app if it ran too long
> (was a machining process with some potential for various hardware
> or software lockups).
sounds like a shell of some type.
>
> Easiest design was to spawn a thread to launch the app and wait
> for it to finish. When it did, the thread wrote to a shared
> status value (writable to the thread, read-only elsewhere) and
> terminated. The main process would periodically check that
> status value. If it didn't show completion in a specified time,
> it set about killing and restarting the app.
aha, a watchdog timer.
>
> Like you, if I had had fork() available, I'd have likely used it,
> although that would have meant implementing IPC of some sort. The
> nice thing was the thread just naturally shared data.
of course, if you had fork(), you would've been on a unix
machine, in which case you would have had mkfifo, and then simply
treated each communication as reading/writing files :-)
goose,
ho ho ho
- Next message: Natasha: "include uploaded by a customer html to jsp"
- Previous message: Thomas Schodt: "Re: How many Internet Explorers have the Sun plug-in installed?"
- In reply to: Programmer Dude: "Re: lines of code?"
- Next in thread: Tim Ward: "Re: lines of code?"
- Reply: Tim Ward: "Re: lines of code?"
- Reply: Programmer Dude: "Re: lines of code?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
