Re: Cpp Considered Harmful

From: Sam Holden (sholden_at_flexal.cs.usyd.edu.au)
Date: 09/02/04 

Date: 2 Sep 2004 00:25:09 GMT

On Wed, 01 Sep 2004 19:30:12 -0400,
        Steven T. Hatton <susudata@setidava.kushan.aa> wrote:
> Sam Holden wrote:
>
>> On Wed, 01 Sep 2004 03:52:53 -0400,
>> Steven T. Hatton <susudata@setidava.kushan.aa> wrote:
>>> Phlip wrote:
>>>
>>>> Steven T. Hatton wrote:
>>>>
>>>>> And you get threadding, unicode, effortless portability, incredibly
>>>>> smooth refactoring, highlevel abstraction with the tools to support it,
>>>>> great,
>>>>
>>>> Threading is good??
>>>
>>> Hu? Even Microsoft eventually figured that out. Yes. Thread support is
>>> crucial for creating any sophisticated application that can be expected
>>> to do more than one thing at a time.
>>
>> Strangely enough I've been using non-threaded applications that
>> do more than one thing at a time and are reasonably sophisticated.
>>
>> Where sophisticated means things like: makes multiple concurrent TCP
>> connections, encodes and decodes audio sending and receiving it over
>> UDP, displays GUI and so on - without a thread in sight (well one
>> thread for the pedants).
>
> OK. Let me be clear as to what I really meant be threading. I really
> intended concurrent programming with resource locking and synchronization.

But you only need resource locking and synchronization because of the
existance of the threads. The code I was thinking about above contains a
fifo queue onto which one "section" of code pushes "events" it has
received via a TCP connection. Another "section" of code pops those
"events" in order to deal with them.

This could use threads - that would be one way to implement it. One
thread would do a blocking read on the network socket and when an event
was received would push it on the queue. Another thread would do a
"blocking pop" (or some equvalient thing) on the queue and deal with the
events. That would require resource locking and synchronization - in
this case the queue is the resource. It would also mean that all the
global data in the program is accessable by both threads. Obviously the
queue needs to be, but due to using threads all the rest of it is too.
Any global data could change state at any time - of course the
programmers will hopefully know which parts of the global state they are
allowed to touch and which need locking and synchronisation. But why
throw away decades of work into systems which can eforce those
restrictions?

In this case my code doesn't use threads, it uses asynchronous events -
when data is available on the socket it gets read and an event pushed on
the queue. To pop from the queue, a callback is provided which is called
when something becomes available and so on. The "main loop" of the
system just multiplexes between the various "sections" according to the
events (button clicks, network sockets changing state, etc).

The disadvantage of this is that on a multiprocessor machine the program
only uses one processor, with threads it could use all of the processors
(well as many as it had threads).

The advantage of this is that no locking is required (which makes things
faster), the programmer doesn't have to worry about "atomic operations"
but can write code knowing that no variable will change value all of a
sudden - no "action at a distance".

> Technically, threading means tracing the same executable image with
> multiple instruction pointers. It's main advantages are the multiple use
> of the same executable image by different 'processes', and the reduced need
> for context switching between processes.
>
>> I even write them occassionaly.
>>
>> Threading throws away decades of work in creating systems with useful
>> protected memory spaces for processes. And lets the average programmer
>> meet all the problems and reinvent (poorly) all the solutions all over
>> again. Rather than using the solution implemented by the (hopefully
>> much more experienced and competent in the domain) OS authors.
>
> What you seem to be suggesting is that threads are used in situations where
> multiple processes would be better. Am I to also understand that all
> concurrency is bad?

Using threads is a *massive* trade off. You are trading off decades of
research and experience into concurrency and system design in order to
get whatever it is threads are giving you (a performance increase?)

The operating system was hopefully designed and implemented by people
who knew what they were doing (which of course may not be the case...)
and who, hopefully, didn't try to reinvent to many of the things like
semaphores.

Threads share memory, the problem is they share all memory (well not
stack and registers, but all "heap" memory if you will). So when you use
threads you have just lost the entire protected memory concept of modern
(and not modern, for that matter) operating systems. You have lost the
resource management handling of the operating system, so you need
to do your own synchronisation.

An obvious alternative is multiple processes and explicitely shared
memory which only contains the data which needs to be shared. That way
the OS can be used to protect the data that doesn't need to be shared,
instead of just trusting no other thread executes buggy code.

Concurrancy doesn't require threads. Threads are one way of achieving
it. How is multiple processes communicating via some form of IPC not
concurrency?

Threads are not all bad, they are the best solution to some problems.
But that set of problems is vanishingly small compared to the
problems threads are usually used to solve...

>
>> Of course there's that vanishingly small percentage of problems that
>> are best solved with threads, but chances are you, me, and the
>> next guy aren't working on one of them.
>
> Please clarify what you mean by 'thread'. I suspect we aren't talking about
> the same thing.

A thread is a concurrently executing entity which has it's own program
counter, registers, stack, and so on but shares main memory with other
threads. That's not a great definition, but hopefully will confirm or
counter your suspicion. 

-- 
Sam Holden
Quantcast