Architecture design
Alessio Sangalli
develop (yes, documentation before the implementation, it's awesome!).
In short, it will run on an embedded platform wint Linux as OS. I have
some hardware devices that have to send data to and receive data from a
server on the network. I will use one TCP stream for all the communication.
Basically what I plan to do is the following:
- for the program to be as modular as possible, it will look in a
directory for "plugins" implemented with shared objects. Every plugin
will declare what "type" or data it will send or receive.
- A "main" thread will start each "plugin" as a separate thread.
- Every "plugin-thread" will manage the hardware; it will eventually
have something to send to the server and viceversa
What is the best way to implement this data exchange? I'd prefer not to
execute code found in the plugin from the "main-thread" because a poorly
written plugin may block for too much time (or indefinitely) the
operations of the rest of the plugins and the data transfer.
An idea I had was to have the main-thread or the plugin-threads insert
data in a thread-safe queue, and then send a signal to the recipient
(main or plugin depending on the data flow) to inform it has to process
the data.
What do you think?
Alessio
Ben Bacarisse
<snip>
> In short, it will run on an embedded platform wint Linux as OS.
comp.unix.programmer is probably a reasonable place to get the overall
design discussed.
<snip>
> An idea I had was to have the main-thread or the plugin-threads insert
> data in a thread-safe queue, and then send a signal to the recipient
> (main or plugin depending on the data flow) to inform it has to process
> the data.
...and if you can't be talked out of using threads,
comp.programming.threads has some very good people on it who can help
with any of these specifics.
--
Ben.
Alessio Sangalli
> comp.unix.programmer is probably a reasonable place to get the overall
> design discussed.
Thanks for the direction
> ...and if you can't be talked out of using threads,
Why does everybody hates threads so much :) I often fail to see the
advantages of processes for 'small' things.
bye
Alessio
Lew Pitcher
(alesanRemo...@manoweb.com) wrote:
> Ben Bacarisse wrote:
[snip]
>> ...and if you can't be talked out of using threads,
>
> Why does everybody hates threads so much :) I often fail to see the
> advantages of processes for 'small' things.
<off-topic>
My guess is that threads are often more bother than they are worth.
Given the possibility of programmed creation of processes (i.e. an api to
launch processes), threads are redundant.
In many environments, threads do not provide any execution-speed advantage
over processes (the usual "big" argument for threads is that "the
context-switch overhead for a thread is 'less' than the context-switch
overhead for a process", but in many systems, threads and processes have
the same context-switch overhead).
Threads usually require a greater level of programming support than
processes.
Programs that use threads often suffer from poor design/implementation,
causing any advantage that threads offer to be lost (I'm thinking of
deadlock and race conditions, and of failure to disentangle logic).
There are as effective ways of data sharing for processes as there are for
threads, and inter-process data sharing usually enforces a level of data
protection that inter-thread data sharing avoids.
HTH
</off-topic>
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
s0s...@gmail.com
> On October 21, 2008 11:34, in comp.lang.c, Alessio Sangalli
> (alesanRemo...@manoweb.com) wrote:
> > Ben Bacarisse wrote:
> [snip]
> >> ...and if you can't be talked out of using threads,
>
> > Why does everybody hates threads so much :) I often fail to see the
> > advantages of processes for 'small' things.
>
> <off-topic>
> My guess is that threads are often more bother than they are worth.
>
> Given the possibility of programmed creation of processes (i.e. an api to
> launch processes), threads are redundant.
fork() is known to be the process creation equivalent to threads
creation, and it provides most of the flexibility that threading does.
However, fork() is less efficient that threads, and much less portable
than threads (since it's only supported on POSIX systems), so even
when fork() is available, threads are not redundant. When fork() is
not available, you can only rely on creation of external processes,
which are much less flexible (e.g., there are less mechanisms for IPC)
and less efficient than threads.
> Threads usually require a greater level of programming support than
> processes.
Maybe, but in a well-designed application (as opposed to in a quick-
and-dirty script), that's the least of the things to worry about. You
just apply an optimal level of abstraction. Furthermore, "greater
level of programming support" often means more functionality, which
results in an increase of simplicity and flexibility in some
application areas such as IPC modeling.
> Programs that use threads often suffer from poor design/implementation,
That has nothing to do with threads themselves. Maybe you've seen a
lot of such applications, but they're poor design is purely their
implementors' fault.
> causing any advantage that threads offer to be lost (I'm thinking of
> deadlock and race conditions, and of failure to disentangle logic).
>
> There are as effective ways of data sharing for processes as there are for
> threads,
When you use fork(), you do have some, but not as many as with
threads. For example, how about a synchronized, shared, global,
producer/consumer queue of data?
> and inter-process data sharing usually enforces a level of data
> protection that inter-thread data sharing avoids.
Sebastian
Keith Thompson
[...]
> fork() is known to be the process creation equivalent to threads
> creation, and it provides most of the flexibility that threading does.
> However, fork() is less efficient that threads, and much less portable
> than threads (since it's only supported on POSIX systems), so even
> when fork() is available, threads are not redundant.
fork() is less portable than threads? Huh?
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
s0s...@gmail.com
> s0s...@gmail.com writes:
>
> [...]> fork() is known to be the process creation equivalent to threads
> > creation, and it provides most of the flexibility that threading does.
> > However, fork() is less efficient that threads, and much less portable
> > than threads (since it's only supported on POSIX systems), so even
> > when fork() is available, threads are not redundant.
>
> [...]
>
> fork() is less portable than threads? Huh?
What do you mean?
Well, strictly speaking, in C, threads are as portable as fork()
(i.e., non-portable), since they're not supported by ISO and you'll
need to rely on system-specific functionality in order to use either
one of them. As far as for POSIX, they're also equivalently portable:
any POSIX system supports both fork() and pthreads.
But what I mean is that threads are supported on a lot of platforms
(in contrast to fork(), which is only available on POSIX systems). In
C/C++, you can use frameworks offering a single interface to the
underlying threading environment. In other languages such as Java or
Python, this interface is already bundled with the language itself.
Sebastian
Richard Heathfield
> s0s...@gmail.com writes:
> [...]
>> fork() is known to be the process creation equivalent to threads
>> creation, and it provides most of the flexibility that threading does.
>> However, fork() is less efficient that threads, and much less portable
>> than threads (since it's only supported on POSIX systems), so even
>> when fork() is available, threads are not redundant.
> [...]
>
> fork() is less portable than threads? Huh?
Bearing in mind that Sebastian is on record as having encountered only
three (I think) installations of C ever, it is possible that *within his
own experience* his observation is accurate. All it would take would be
for fork() only to be available on one of his systems, whilst he happened
to have two systems that both supported threads in the same way.
Small sample sizes can be very misleading.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Joachim Schmitz
> On Oct 22, 1:19 am, Keith Thompson <k...@sdsc.edu> wrote:
>> s0s...@gmail.com writes:
>>
>> [...]> fork() is known to be the process creation equivalent to
>> threads
>>> creation, and it provides most of the flexibility that threading
>>> does. However, fork() is less efficient that threads, and much less
>>> portable than threads (since it's only supported on POSIX systems),
>>> so even when fork() is available, threads are not redundant.
>>
>> [...]
>>
>> fork() is less portable than threads? Huh?
>
> What do you mean?
>
> Well, strictly speaking, in C, threads are as portable as fork()
> (i.e., non-portable), since they're not supported by ISO and you'll
> need to rely on system-specific functionality in order to use either
> one of them. As far as for POSIX, they're also equivalently portable:
> any POSIX system supports both fork() and pthreads.
Huh? I don't think so. There are POSIX threads, yes, but in a different
POSIX standard as fork().
> But what I mean is that threads are supported on a lot of platforms
> (in contrast to fork(), which is only available on POSIX systems). In
> C/C++, you can use frameworks offering a single interface to the
> underlying threading environment. In other languages such as Java or
> Python, this interface is already bundled with the language itself.
I'd bet that there are more system supporting POIX for then there are
supporting POSIX threads.
> Sebastian
Bye, Jojo
Richard Heathfield
> On Oct 22, 1:19 am, Keith Thompson <k...@sdsc.edu> wrote:
<snip>
>> fork() is less portable than threads? Huh?
>
> What do you mean?
>
> Well, strictly speaking, in C, threads are as portable as fork()
> (i.e., non-portable),
So when you say "less portable than", you mean "as portable as"? Odd.
> since they're not supported by ISO and you'll
> need to rely on system-specific functionality in order to use either
> one of them. As far as for POSIX, they're also equivalently portable:
> any POSIX system supports both fork() and pthreads.
>
> But what I mean is that threads are supported on a lot of platforms
> (in contrast to fork(), which is only available on POSIX systems).
The fact that threads are supported on Platform A and Platform B doesn't
make threaded code portable between A and B *unless* the same interface
and semantics are available on both platforms. This is by no means always
the case.
> In C/C++, you can use frameworks offering a single interface to the
> underlying threading environment.
If you really need to use threads, that's obviously a good way to go. But
of course most programs would be better off without them.
Joachim Schmitz
Typos, sorry, should read:
> I'd bet that there are more system supporting POSIX fork than there are
> supporting POSIX threads.
s0s...@gmail.com
> Keith Thompson said:
>
> > s0s...@gmail.com writes:
> > [...]
> >> fork() is known to be the process creation equivalent to threads
> >> creation, and it provides most of the flexibility that threading does.
> >> However, fork() is less efficient that threads, and much less portable
> >> than threads (since it's only supported on POSIX systems), so even
> >> when fork() is available, threads are not redundant.
> > [...]
>
> > fork() is less portable than threads? Huh?
>
> Bearing in mind that Sebastian is on record as having encountered only
> three (I think) installations of C ever, it is possible that *within his
> own experience* his observation is accurate.
But I was trying to account for all platforms in general. If you think
that what I said isn't accurate outside personal experiences (which
have no practical value), stop with the word games and just say so.
Sebastian
s0s...@gmail.com
> s0s...@gmail.com said:
>
> > On Oct 22, 1:19 am, Keith Thompson <k...@sdsc.edu> wrote:
>
> <snip>
>
> >> fork() is less portable than threads? Huh?
>
> > What do you mean?
>
> > Well, strictly speaking, in C, threads are as portable as fork()
> > (i.e., non-portable),
>
> So when you say "less portable than", you mean "as portable as"? Odd.
When I said "less portable than" in my first post, I was speaking
generally. Then I said "as portable as", qualifying it with the phrase
"strictly speaking". Those are two different contexts.
> > since they're not supported by ISO and you'll
> > need to rely on system-specific functionality in order to use either
> > one of them. As far as for POSIX, they're also equivalently portable:
> > any POSIX system supports both fork() and pthreads.
>
> > But what I mean is that threads are supported on a lot of platforms
> > (in contrast to fork(), which is only available on POSIX systems).
>
> The fact that threads are supported on Platform A and Platform B doesn't
> make threaded code portable between A and B *unless* the same interface
> and semantics are available on both platforms. This is by no means always
> the case.
And what on earth is stopping you from using a portable interface?
> > In C/C++, you can use frameworks offering a single interface to the
> > underlying threading environment.
>
> If you really need to use threads, that's obviously a good way to go. But
> of course most programs would be better off without them.
Either you need them or you don't, of course. I'm just saying that
they have significant advantages over processes in general.
Sebastian
Richard Heathfield
> On Oct 22, 2:07 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>> Keith Thompson said:
>>
>> > s0s...@gmail.com writes:
>> > [...]
>> >> fork() is known to be the process creation equivalent to threads
>> >> creation, and it provides most of the flexibility that threading
>> >> does. However, fork() is less efficient that threads, and much less
>> >> portable than threads (since it's only supported on POSIX systems),
>> >> so even when fork() is available, threads are not redundant.
>> > [...]
>>
>> > fork() is less portable than threads? Huh?
>>
>> Bearing in mind that Sebastian is on record as having encountered only
>> three (I think) installations of C ever, it is possible that *within his
>> own experience* his observation is accurate.
>
> But I was trying to account for all platforms in general.
Then I think you failed.
> If you think
> that what I said isn't accurate outside personal experiences (which
> have no practical value), stop with the word games and just say so.
I did say so, pretty much, and I wasn't playing word games. But I disagree
that personal experiences have no practical value. On the contrary, they
have enormous practical value. But they are not always as mappable onto
other people's experiences as we might think.
In my own personal experience, neither fork() nor threads are especially
portable, and to argue about which is *more* portable seems to me to be an
angels-on-pinheads discussion.
Richard Heathfield
> On Oct 22, 2:15 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>> s0s...@gmail.com said:
>>
<snip>
>> > But what I mean is that threads are supported on a lot of platforms
>> > (in contrast to fork(), which is only available on POSIX systems).
>>
>> The fact that threads are supported on Platform A and Platform B doesn't
>> make threaded code portable between A and B *unless* the same interface
>> and semantics are available on both platforms. This is by no means
>> always the case.
>
> And what on earth is stopping you from using a portable interface?
Partly non-availability. There isn't an interface that's portable *enough*.
And partly common sense. Threads were invented for people who can't write
state machines (which, incidentally, are far easier to debug).
>> > In C/C++, you can use frameworks offering a single interface to the
>> > underlying threading environment.
>>
>> If you really need to use threads, that's obviously a good way to go.
>> But of course most programs would be better off without them.
>
> Either you need them or you don't, of course. I'm just saying that
> they have significant advantages over processes in general.
That sounds like a factoid to me (like the factoid that "integer operations
are faster than floating-point operations"). And threads have significant
*dis*advantages that should not be glossed over.
s0s...@gmail.com
> s0s...@gmail.com said:
> > If you think
> > that what I said isn't accurate outside personal experiences (which
> > have no practical value), stop with the word games and just say so.
>
> I did say so, pretty much, and I wasn't playing word games. But I disagree
> that personal experiences have no practical value. On the contrary, they
> have enormous practical value. But they are not always as mappable onto
> other people's experiences as we might think.
>
> In my own personal experience, neither fork() nor threads are especially
> portable, and to argue about which is *more* portable seems to me to be an
> angels-on-pinheads discussion.
Then you haven't used anything but C. Like I said earlier, there are
languages such as Python and Java that try to provide portable
interfaces to operating system services. On such languages, you'll be
able to write a portable threading application (without having to rely
on third-party libraries) that will work on any system where there is
an implementation of the language and that supports threads. The same
is not possible with fork(), since it's only available on POSIX
systems.
Sebastian
Richard Heathfield
> On Oct 22, 2:32 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>> s0s...@gmail.com said:
>> > If you think
>> > that what I said isn't accurate outside personal experiences (which
>> > have no practical value), stop with the word games and just say so.
>>
>> I did say so, pretty much, and I wasn't playing word games. But I
>> disagree that personal experiences have no practical value. On the
>> contrary, they have enormous practical value. But they are not always as
>> mappable onto other people's experiences as we might think.
>>
>> In my own personal experience, neither fork() nor threads are especially
>> portable, and to argue about which is *more* portable seems to me to be
>> an angels-on-pinheads discussion.
>
> Then you haven't used anything but C.
Thanks for letting me know. I was under the impression that I have used and
do use a number of other languages, but clearly I was wrong about that.
> Like I said earlier, there are
> languages such as Python and Java that try to provide portable
> interfaces to operating system services.
Yes, they try. And surprisingly often they succeed. But if you think that
Python and Java are more portable than C, you have an astoundingly limited
view of computing.
s0s...@gmail.com
> s0s...@gmail.com said:
>
> > On Oct 22, 2:15 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> s0s...@gmail.com said:
>
> <snip>
>
> >> > But what I mean is that threads are supported on a lot of platforms
> >> > (in contrast to fork(), which is only available on POSIX systems).
>
> >> The fact that threads are supported on Platform A and Platform B doesn't
> >> make threaded code portable between A and B *unless* the same interface
> >> and semantics are available on both platforms. This is by no means
> >> always the case.
>
> > And what on earth is stopping you from using a portable interface?
>
> Partly non-availability. There isn't an interface that's portable *enough*.
Perhaps one of the best I've seen is Mozilla's NSPR.
> And partly common sense. Threads were invented for people who can't write
> state machines (which, incidentally, are far easier to debug).
Do state machines really have anything to do with parallel processing?
> >> > In C/C++, you can use frameworks offering a single interface to the
> >> > underlying threading environment.
>
> >> If you really need to use threads, that's obviously a good way to go.
> >> But of course most programs would be better off without them.
>
> > Either you need them or you don't, of course. I'm just saying that
> > they have significant advantages over processes in general.
>
> That sounds like a factoid to me (like the factoid that "integer operations
> are faster than floating-point operations"). And threads have significant
> *dis*advantages that should not be glossed over.
That would sound much more convincing if you stated what disadvantages
those are, and how you can avoid them using processes or state
machines.
Sebastian
s0s...@gmail.com
> s0s...@gmail.com said:
> > Like I said earlier, there are
> > languages such as Python and Java that try to provide portable
> > interfaces to operating system services.
>
> Yes, they try. And surprisingly often they succeed. But if you think that
> Python and Java are more portable than C, you have an astoundingly limited
> view of computing.
Those languages are portable in a different sense than C is. C tries
to be portable across a wide range of platforms at the cost of failing
to provide many system services that may not be available under those
platforms, which greatly reduces its usability. Java and Python try to
be portable across a wide range of platforms while still providing
interfaces to as many system services as possible, at the cost of
being unable to provide those services on systems where they're not
available, and thus creating ambiguities in the interfaces on those
systems.
Unfortunately, we don't have both of those meanings of portability in
a single language yet.
Sebastian
Nick Keighley
> On October 21, 2008 11:34, in comp.lang.c, Alessio Sangalli
> > Ben Bacarisse wrote:
> >> ...and if you can't be talked out of using threads,
>
> > Why does everybody hates threads so much :) I often fail to see the
> > advantages of processes for 'small' things.
no one said "if you don't use threads then use processes". Why not use
neither of them?
> <off-topic>
> My guess is that threads are often more bother than they are worth.
>
> Given the possibility of programmed creation of processes (i.e. an api to
> launch processes), threads are redundant.
well, no. If you *have to have parralleism" (and I'd argue the average
application has a lot less of it than some people think) then
processes
can be very heavy weight. I worked on a system that scaled badly.
It started so many processes it took *hours* to start.
> In many environments, threads do not provide any execution-speed advantage
> over processes (the usual "big" argument for threads is that "the
> context-switch overhead for a thread is 'less' than the context-switch
> overhead for a process", but in many systems, threads and processes have
> the same context-switch overhead).
>
> Threads usually require a greater level of programming support than
> processes.
>
> Programs that use threads often suffer from poor design/implementation,
> causing any advantage that threads offer to be lost (I'm thinking of
> deadlock and race conditions, and of failure to disentangle logic).
>
> There are as effective ways of data sharing for processes as there are for
> threads, and inter-process data sharing usually enforces a level of data
> protection that inter-thread data sharing avoids.
and this is *all* avoided if you use neitehr threads no processes.
--
Nick Keighley
Richard Heathfield
> On Oct 22, 2:36 am, Richard Heathfield <r...@see.sig.invalid> wrote:
<snip>
>> Threads were invented for people who can't
>> write state machines (which, incidentally, are far easier to debug).
>
> Do state machines really have anything to do with parallel processing?
Most people who use threads do so not because they need parallel
processing, but because they think they do. For example, it's commonplace
to see server code with one thread per client, which is a ludicrous misuse
of resources. In a great many cases, threads are simply not a good fit to
the problem. (This says nothing about their portability, of course.)
>> >> > In C/C++, you can use frameworks offering a single interface to the
>> >> > underlying threading environment.
>>
>> >> If you really need to use threads, that's obviously a good way to go.
>> >> But of course most programs would be better off without them.
>>
>> > Either you need them or you don't, of course. I'm just saying that
>> > they have significant advantages over processes in general.
>>
>> That sounds like a factoid to me (like the factoid that "integer
>> operations are faster than floating-point operations"). And threads have
>> significant *dis*advantages that should not be glossed over.
>
> That would sound much more convincing if you stated what disadvantages
> those are, and how you can avoid them using processes or state
> machines.
If you don't know already, I see little value in continuing this
discussion. But that doesn't mean I'm ducking the question.
The most obvious disadvantage is that threads can compete over object
values. Thread A might try to read the value whilst Thread B is in the
middle of updating that value, for example. So you have to do the whole
semaphore/mutex thing. And you have to be careful to avoid a deadlock,
where Thread A has locked resource C and is waiting for resource D,
whereas Thread B has locked resource D and is waiting for resource C.
Writing thread-safe code is a far from trivial exercise. Writing a state
machine solution is much simpler and generally less bug-prone (at least,
in my experience).
Nick Keighley
> On Oct 21, 11:30 am, Lew Pitcher <lpitc...@teksavvy.com> wrote:
> > On October 21, 2008 11:34, in comp.lang.c, Alessio Sangalli
> > > Ben Bacarisse wrote:
> > >> ...and if you can't be talked out of using threads,
>
> > > Why does everybody hates threads so much :) I often fail to see the
> > > advantages of processes for 'small' things.
>
> > <off-topic>
> > My guess is that threads are often more bother than they are worth.
>
> > Given the possibility of programmed creation of processes (i.e. an api to
> > launch processes), threads are redundant.
>
> fork() is known to be the process creation equivalent to threads
> creation, and it provides most of the flexibility that threading does.
> However, fork() is less efficient that threads, and much less portable
> than threads (since it's only supported on POSIX systems),
you are comparing oranges with orchards.
threads and processes are the things to compare. fork()
is just one OS specific way of creating processes.
Compare like with like if you are going to talk portability.
> so even
> when fork() is available, threads are not redundant. When fork() is
> not available, you can only rely on creation of external processes,
> which are much less flexible (e.g., there are less mechanisms for IPC)
> and less efficient than threads.
why? Why are fork-less system less flexible. What is the connection
between process creation and IPC?
<snip>
> > Programs that use threads often suffer from poor design/implementation,
>
> That has nothing to do with threads themselves. Maybe you've seen a
> lot of such applications, but they're poor design is purely their
> implementors' fault.
fair point. People can write crap in any language.
Tho' threads are pretty easy to make mistakes with...
<snip>
--
Nick Keighley
Antoninus Twink
> fork() is known to be the process creation equivalent to threads
> creation, and it provides most of the flexibility that threading does.
> However, fork() is less efficient that threads, and much less portable
> than threads (since it's only supported on POSIX systems), so even
> when fork() is available, threads are not redundant. When fork() is
> not available, you can only rely on creation of external processes,
> which are much less flexible (e.g., there are less mechanisms for IPC)
> and less efficient than threads.
I don't really agree with this assessment.
I'd say that for communication purposes, fork()ed processes are much
less flexible than threads, and an external process provides most of the
flexibility of a fork()ed process.
OK, so you have some nice conveniences with fork() like being able to
open a pipe, have the file descriptors copied to the child, then use it
for parent-to-child or child-to-parent communication, but IPC between a
parent and child process isn't really much easier or more convenient
than between two arbitrary processes.
s0s...@gmail.com
> s0s...@gmail.com said:
>
> > On Oct 22, 2:36 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> <snip>
>
> >> Threads were invented for people who can't
> >> write state machines (which, incidentally, are far easier to debug).
>
> > Do state machines really have anything to do with parallel processing?
>
> Most people who use threads do so not because they need parallel
> processing, but because they think they do. For example, it's commonplace
> to see server code with one thread per client, which is a ludicrous misuse
> of resources. In a great many cases, threads are simply not a good fit to
> the problem. (This says nothing about their portability, of course.)
How do you propose writing a server that needs to handle multiple
clients synchronously without parallel processing? The only
alternative I've heard so far is select(), but it's only optimal if
the server isn't receiving too many requests.
> >> >> > In C/C++, you can use frameworks offering a single interface to the
> >> >> > underlying threading environment.
>
> >> >> If you really need to use threads, that's obviously a good way to go.
> >> >> But of course most programs would be better off without them.
>
> >> > Either you need them or you don't, of course. I'm just saying that
> >> > they have significant advantages over processes in general.
>
> >> That sounds like a factoid to me (like the factoid that "integer
> >> operations are faster than floating-point operations"). And threads have
> >> significant *dis*advantages that should not be glossed over.
>
> > That would sound much more convincing if you stated what disadvantages
> > those are, and how you can avoid them using processes or state
> > machines.
>
> If you don't know already, I see little value in continuing this
> discussion. But that doesn't mean I'm ducking the question.
>
> The most obvious disadvantage is that threads can compete over object
> values. Thread A might try to read the value whilst Thread B is in the
> middle of updating that value, for example. So you have to do the whole
> semaphore/mutex thing. And you have to be careful to avoid a deadlock,
> where Thread A has locked resource C and is waiting for resource D,
> whereas Thread B has locked resource D and is waiting for resource C.
>
> Writing thread-safe code is a far from trivial exercise. Writing a state
> machine solution is much simpler and generally less bug-prone (at least,
> in my experience).
I think writing thread-safe code is trivial once you adopt the set of
coding practices that lead to thread-safe code. Dealing with the
threads themselves may be less trivial, but it's the cost of having
the added functionality. Anyway, remember the old saying
"Keep it simple: as simple as possible, but no simpler."
I think you're trying to keep it simpler :-)
Sebastian
Richard Heathfield
> On Oct 22, 3:26 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>> s0s...@gmail.com said:
>>
>> > On Oct 22, 2:36 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>>
>> <snip>
>>
>> >> Threads were invented for people who can't
>> >> write state machines (which, incidentally, are far easier to debug).
>>
>> > Do state machines really have anything to do with parallel processing?
>>
>> Most people who use threads do so not because they need parallel
>> processing, but because they think they do. For example, it's
>> commonplace to see server code with one thread per client, which is a
>> ludicrous misuse of resources. In a great many cases, threads are simply
>> not a good fit to the problem. (This says nothing about their
>> portability, of course.)
>
> How do you propose writing a server that needs to handle multiple
> clients synchronously without parallel processing?
One problem with off-topic discussions is that it's difficult to know where
to draw a line.
> The only
> alternative I've heard so far is select(), but it's only optimal if
> the server isn't receiving too many requests.
Yes, you use select(). If you have too many requests, you add servers.
Servers are cheap.
<snip>
>>
>> Writing thread-safe code is a far from trivial exercise. Writing a state
>> machine solution is much simpler and generally less bug-prone (at least,
>> in my experience).
>
> I think writing thread-safe code is trivial once you adopt the set of
> coding practices that lead to thread-safe code.
I have quite a few programs installed on this machine that were written by
people who think as you do. These programs crash rather often.
> Dealing with the
> threads themselves may be less trivial, but it's the cost of having
> the added functionality. Anyway, remember the old saying
>
> "Keep it simple: as simple as possible, but no simpler."
>
> I think you're trying to keep it simpler :-)
Think as you will, but I disagree.
s0s...@gmail.com
> On 22 Oct 2008 at 0:01, s0s...@gmail.com wrote:
>
> > fork() is known to be the process creation equivalent to threads
> > creation, and it provides most of the flexibility that threading does.
> > However, fork() is less efficient that threads, and much less portable
> > than threads (since it's only supported on POSIX systems), so even
> > when fork() is available, threads are not redundant. When fork() is
> > not available, you can only rely on creation of external processes,
> > which are much less flexible (e.g., there are less mechanisms for IPC)
> > and less efficient than threads.
>
> I don't really agree with this assessment.
>
> I'd say that for communication purposes, fork()ed processes are much
> less flexible than threads,
Yes, that's what I said.
> and an external process provides most of the
> flexibility of a fork()ed process.
>
> OK, so you have some nice conveniences with fork() like being able to
> open a pipe, have the file descriptors copied to the child, then use it
> for parent-to-child or child-to-parent communication, but IPC between a
> parent and child process isn't really much easier or more convenient
> than between two arbitrary processes.
How isn't it more easier or convenient if you have those mechanisms
available? With external processes, all you have are the standard I/O
streams connected as pipes between the processes. The OS may provide
more specialized IPC mechanisms (such as UNIX domain sockets, under
UNIX, or just Internet domain sockets connected to the loopback
interface), but these are very non-portable and usually lead to a
great increase in complexity.
Sebastian
Ian Collins
> s0s...@gmail.com said:
>> I think writing thread-safe code is trivial once you adopt the set of
>> coding practices that lead to thread-safe code.
>
> I have quite a few programs installed on this machine that were written by
> people who think as you do. These programs crash rather often.
>
It's seldom trivial, but thread-safe programming is a skill well worth
mastering in these days of multi-core CPUs. I can't remember the last
time I used a single core desktop.
Would you be happy if the developers of your OS shared your Luddite
attitude and refused to build a threaded kernel?
--
Ian Collins
s0s...@gmail.com
wrote:
> On 22 Oct, 01:01, s0s...@gmail.com wrote:
>> On Oct 21, 11:30 am, Lew Pitcher <lpitc...@teksavvy.com> wrote:
>>> On October 21, 2008 11:34, in comp.lang.c, Alessio Sangalli
>>> (alesanRemoveMePle...@manoweb.com) wrote:
>>>> Ben Bacarisse wrote:
>>>>> ...and if you can't be talked out of using threads,
>
>>>> Why does everybody hates threads so much :) I often fail to see the
>>>> advantages of processes for 'small' things.
>
>>> <off-topic>
>>> My guess is that threads are often more bother than they are worth.
>
>>> Given the possibility of programmed creation of processes (i.e. an api to
>>> launch processes), threads are redundant.
>
>> fork() is known to be the process creation equivalent to threads
>> creation, and it provides most of the flexibility that threading does.
>> However, fork() is less efficient that threads, and much less portable
>> than threads (since it's only supported on POSIX systems),
>
> you are comparing oranges with orchards.
>
> threads and processes are the things to compare. fork()
> is just one OS specific way of creating processes.
> Compare like with like if you are going to talk portability.
I was comparing threads with fork() because, as far as I can see,
fork() is the way to create a process that provides the most
flexibility (e.g., you can set up things like pipes right before the
fork for IPC).
> > so even
> > when fork() is available, threads are not redundant. When fork() is
> > not available, you can only rely on creation of external processes,
> > which are much less flexible (e.g., there are less mechanisms for IPC)
> > and less efficient than threads.
>
> why? Why are fork-less system less flexible. What is the connection
> between process creation and IPC?
Well, when your process divides into two threads or two processes, you
sometimes need those two threads or processes to continue
communicating. For example, sometimes programs spawn a producer thread
that does some computation and then places the gathered information in
a global data structure, which a consumer thread will check
periodically. (This is often the case in GUI programs, where the
"consumer" thread is the main thread which handles the windows, and
the "producer" thread is the one that does the long-running task so
that the windows can remain active.) IPC is one of the main things
that makes parallel processing useful; if processes or threads just
went on their own after creation, their use would be very limited.
<snip>
Sebastian
Antoninus Twink
> On Oct 22, 3:41 am, Antoninus Twink <nos...@nospam.invalid> wrote:
>> On 22 Oct 2008 at 0:01, s0s...@gmail.com wrote:
>> > fork() is known to be the process creation equivalent to threads
>> > creation, and it provides most of the flexibility that threading does.
>>
>>
>> I'd say that for communication purposes, fork()ed processes are much
>> less flexible than threads,
>
> Yes, that's what I said.
Well, you actually said that fork() provides most of the flexibility
that threading does... but let's not get into silly word games like the
"regulars" play.
>> OK, so you have some nice conveniences with fork() like being able to
>> open a pipe, have the file descriptors copied to the child, then use it
>> for parent-to-child or child-to-parent communication, but IPC between a
>> parent and child process isn't really much easier or more convenient
>> than between two arbitrary processes.
>
> How isn't it more easier or convenient if you have those mechanisms
> available?
It can be easier and more convenient in some circumstances, as I said.
But the extra options available to you for IPC between parent and child
processes versus two arbitrary processes are extremely limited.
> With external processes, all you have are the standard I/O streams
> connected as pipes between the processes. The OS may provide more
> specialized IPC mechanisms (such as UNIX domain sockets, under UNIX,
> or just Internet domain sockets connected to the loopback interface),
> but these are very non-portable
Sockets and pipes are both specified by POSIX, and both are widely
portable.
> and usually lead to a great increase in complexity.
IPC is inherently complex.
Antoninus Twink
> In my own personal experience, neither fork() nor threads are
> especially portable, and to argue about which is *more* portable seems
> to me to be an angels-on-pinheads discussion.
I wondered what it was that drew you to this discussion that normally
you'd exclude as "off topic" - the lure of another angels-on-pinheads
discussion was too much.
Antoninus Twink
>> optimal if the server isn't receiving too many requests.
>
> Yes, you use select(). If you have too many requests, you add servers.
> Servers are cheap.
Presumably you are trying to be sarcastic, but it's obviously true that
*whatever* programming methodology you use, threads or not, resources
will still be finite, so at the end of the day if you get more requests
than you can satisfy then adding resources is the only solution.
Nick Keighley
> On Oct 22, 3:26 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
but if we are going to discuss portability you need to compare
comparable things (actually I think that applies much more generally!
:-) )
> > > so even
> > > when fork() is available, threads are not redundant. When fork() is
> > > not available, you can only rely on creation of external processes,
> > > which are much less flexible (e.g., there are less mechanisms for IPC)
> > > and less efficient than threads.
>
> > why? Why are fork-less system less flexible. What is the connection
> > between process creation and IPC?
>
> Well, when your process divides into two threads or two processes, you
> sometimes need those two threads or processes to continue
> communicating. For example, sometimes programs spawn a producer thread
> that does some computation and then places the gathered information in
> a global data structure, which a consumer thread will check
> periodically. (This is often the case in GUI programs, where the
> "consumer" thread is the main thread which handles the windows, and
> the "producer" thread is the one that does the long-running task so
> that the windows can remain active.) IPC is one of the main things
> that makes parallel processing useful; if processes or threads just
> went on their own after creation, their use would be very limited.
you appear to have answered a different a question from the one I
asked.
I said " What is the connection between process creation and IPC?".
You seem to be explaining why processes (or threads need to
communicate.
I agree if P/Ts were unable to communicate there would be little
point
in having them.
What does this have to do with the method of process creation?
[basically I don't accept your point that not using fork
automatically precludes using various forms of inter-process
communication]
--
Nick Keighley
Nick Keighley
> On Oct 22, 3:08 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> > s0s...@gmail.com said:
> > > Like I said earlier, there are
> > > languages such as Python and Java that try to provide portable
> > > interfaces to operating system services.
>
> > Yes, they try. And surprisingly often they succeed. But if you think that
> > Python and Java are more portable than C, you have an astoundingly limited
> > view of computing.
>
> Those languages are portable in a different sense than C is. C tries
> to be portable across a wide range of platforms at the cost of failing
> to provide many system services that may not be available under those
> platforms, which greatly reduces its usability. Java and Python try to
> be portable across
[a much narrower]
> range of platforms while still providing
> interfaces to as many system services as possible, at the cost of
> being unable to provide those services on systems where they're not
> available, and thus creating ambiguities in the interfaces on those
> systems.
>
> Unfortunately, we don't have both of those meanings of portability in
> a single language yet.
I don't think it is, even in principle, possible. We will always
have both mainframes and toasters.
--
Nick Keighley
With Y2K behind us,
there's nearly 8000 years until we need COBOL programmers again!
Richard Heathfield
> Richard Heathfield wrote:
>> s0s...@gmail.com said:
>
>>> I think writing thread-safe code is trivial once you adopt the set of
>>> coding practices that lead to thread-safe code.
>>
>> I have quite a few programs installed on this machine that were written
>> by people who think as you do. These programs crash rather often.
>>
> It's seldom trivial, but thread-safe programming is a skill well worth
> mastering in these days of multi-core CPUs.
I agree entirely. I am not arguing that threads should not be used. I am
arguing that they are over-used.
> I can't remember the last
> time I used a single core desktop.
>
> Would you be happy if the developers of your OS shared your Luddite
> attitude and refused to build a threaded kernel?
You seem to be attempting to extend my position. I have not said that
nobody should use threads. Nor have I said that I never use threads. (In
fact, I rarely use them, but rarely != never.) What I have said is that
people often use threads when it is inappropriate, and I don't agree that
such a position is Luddite. Nor do I think it is Luddite to point out that
many people who use threads do so in sub-optimal ways (to put it too
mildly).
Kenny McCormack
>> creation, and it provides most of the flexibility that threading does.
>> However, fork() is less efficient that threads, and much less portable
>> when fork() is available, threads are not redundant.
>
>fork() is less portable than threads? Huh?
Windows has threads but not fork. That's a big chunk of the world.
Jensen Somers
Windows does indeed not provide the function fork() as POSIX does, but
just as threads are implemented Windows has a function called
CreateProcess() [1] which basically does what fork() does.
[1] http://msdn.microsoft.com/en-us/library/ms682425.aspx
--
Jensen Somers <http://jsomers.eu>
Email: -http:// +jensen@
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning."
- Rick Cook, The Wizardry Compiled
Joachim Schmitz
Does it have POSIX threads?
Bye, Jojo
Kenny McCormack
Jensen Somers <jen...@see.sig.invalid> wrote:
>Kenny McCormack wrote:
>> In article <87y70h1...@kvetch.smov.org>,
>> Keith Thompson <k...@sdsc.edu> wrote:
>>> s0s...@gmail.com writes:
>>> [...]
>>>> fork() is known to be the process creation equivalent to threads
>>>> creation, and it provides most of the flexibility that threading does.
>>>> However, fork() is less efficient that threads, and much less portable
>>>> than threads (since it's only supported on POSIX systems), so even
>>>> when fork() is available, threads are not redundant.
>>> [...]
>>>
>>> fork() is less portable than threads? Huh?
>>
>> Windows has threads but not fork. That's a big chunk of the world.
Note: I'm not defending or justifying Windows (or any other OS).
I'm just trying to clarify (IMHO, of course) what the OP was saying.
>Windows does indeed not provide the function fork() as POSIX does, but
>just as threads are implemented Windows has a function called
>CreateProcess() [1] which basically does what fork() does.
Again, I'm not advocating anything.
But, the point is that every OS has some kind of "spawn process"
functionality - but Unix has a particular (and, in a way, peculiar) way
of doing it. fork() has semantics not found (AFAIK) outside the Unix
world. As has been noted many times, 99.99% of the time, fork() is
followed by exec(), but it need not be. That last is the significant
thing.
Threads, OTOH, are a more general concept than fork(). Therefore, OSs
are free to implement them as they please.
P.S. Of course, the OP's phrasing is open to some good old fashioned
CLC-style nitpicking. To wit, comparing "threads" and "fork()" is like
comparing "output to a terminal or file" with "write()".
Antoninus Twink
> Kenny McCormack wrote:
>> Windows has threads but not fork. That's a big chunk of the world.
>
> Windows does indeed not provide the function fork() as POSIX does, but
> just as threads are implemented Windows has a function called
> CreateProcess() [1] which basically does what fork() does.
>
> [1] http://msdn.microsoft.com/en-us/library/ms682425.aspx
Interesting. I assume that if the bInheritHandles parameter is true then
the new process gets copies of the creator's file descriptors (is that
what a handle is?), so that the two processes can communicate along an
anonymous pipe as we were discussing for fork().
Personally, I'm still not convinced that this is an overwhelming
advantage over named pipes or other methods of IPC that work for any two
processes, not just a parent and child.
Ian Collins
Kenny McCormack
FSVO "It".
Rhetorical question: Does Windows have fork()?
Rhetorical answer: Yes: http://www.cygwin.com
David Thompson
<jen...@see.sig.invalid> wrote:
> Kenny McCormack wrote:
> > In article <87y70h1...@kvetch.smov.org>,
> > Keith Thompson <k...@sdsc.edu> wrote:
> >> fork() is less portable than threads? Huh?
> >
> > Windows has threads but not fork. That's a big chunk of the world.
> >
>
> Windows does indeed not provide the function fork() as POSIX does, but
> just as threads are implemented Windows has a function called
> CreateProcess() [1] which basically does what fork() does.
>
> [1] http://msdn.microsoft.com/en-us/library/ms682425.aspx
Win32 CreateProcess does approximately (modulo other Win/Unix
differences) what fork PLUS exec*, or equivalently spawn, does.
Most uses of fork are part of fork+exec, and thus can be
converted/ported adequately, but not all. Converting uses that are
truly just fork (and nontrivial) are more involved.
- formerly david.thompson1 || achar(64) || worldnet.att.net
Alessio Sangalli
> no one said "if you don't use threads then use processes". Why not use
> neither of them?
Why do you imply the application will have a single CPU? Nowadays even
embedded systems are at least dual core, not to mention prototypes that
are around with hundreds of cores.
bye
as
Nick Keighley
wrote:
> Nick Keighley wrote:
> > no one said "if you don't use threads then use processes". Why not use
> > neither of them?
>
> Why do you imply the application will have a single CPU?
that wasn't my intent
> Nowadays even
> embedded systems are at least dual core,
really? Even toasters?
> not to mention prototypes that
> are around with hundreds of cores.
fine, you want massive parallelism then use threads.
I'm arguing there are plenty of applications that don't
need the hassle.
--
Nick Keighley
Flash Gordon
> On 2 Dec, 06:53, Alessio Sangalli <alesanRemoveMePle...@manoweb.com>
> wrote:
>> Nick Keighley wrote:
>
>>> no one said "if you don't use threads then use processes". Why not use
>>> neither of them?
>> Why do you imply the application will have a single CPU?
>
> that wasn't my intent
>
>> Nowadays even
>> embedded systems are at least dual core,
>
> really? Even toasters?
Toasters? They have a lot of power compared to some devices!
>> not to mention prototypes that
>> are around with hundreds of cores.
>
> fine, you want massive parallelism then use threads.
> I'm arguing there are plenty of applications that don't
> need the hassle.
Oh indeed. Even a number of multi-user applications don't need it (I'm
thinking an ap with 200+ simultaneous users where each one gets an
independent process with just record locking occuring between them.
--
Flash Gordon
If spamming me sent it to sm...@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/