Why threads vs events is a nonsensical question.

by xtacy • 15 years ago

92 46 15 years ago

nknight4• 15 years ago

YES. THANK YOU. I was just ranting about this elsewhere. People go "threads are evil" with vague rationales about getting locks right and such, and insist we all use separate heavyweight processes. It's ridiculous.

Selection of sane data structures and communication channels can get you virtually all of the safety and ease of separate processes WITH the performance benefits of a shared memory space.

It reminds me of people that criticize C++ for allowing memory leaks. There as here, simply selecting the right primitives and development strategy in advance make the problem simply disappear.

dkersten2• 15 years ago

People go "threads are evil" with vague rationales about getting locks right and such, and insist we all use separate heavyweight processes. It's ridiculous.

Nevermind the fact that (almost) all the things that (supposedly) make threads evil are still there when you use heavyweight processes.

masklinn4• 15 years ago

The one thing that makes threads evil is shared memory, especially when doing so unknowingly.

You can't share memory unknowingly with processes, when you can share memory at all.

masklinn4• 15 years ago

> People go "threads are evil" with vague rationales about getting locks right and such, and insist we all use separate heavyweight processes.

Insisting processes be used != insisting OS processes be used. Although most language don't give any choice in the matter.

> Selection of sane data structures and communication channels can get you virtually all of the safety and ease of separate processes

It gives you none of the safety, as you have to be very careful in ensuring no mutable datastructure is ever shared unknowingly. When using processes, you can't share memory implicitly, which is safe.

> There as here, simply selecting the right primitives and development strategy in advance make the problem simply disappear.

That's bullshit. It may make the problem less prominent, but it can not make the problem disappear.

nknight4• 15 years ago

So you go from distinguishing between processes on the language and OS levels, to categorically declaring you can't share memory implicitly with processes.

A facsimile of a process that isn't implemented as an actual process is going to be in a shared address space. Your pet bondage-and-discipline language might work to prevent one pseudo-process from interfering with another, but I don't see it being equal to full-blown processes, nor do I see it being substantively more trustworthy than making a few simple, easy decisions about how to structure your programs.

marshray2• 15 years ago

It may make the problem less prominent, but it can not make the problem disappear.

It would look quite weird and most other programmers would think you were crazy for having done it, I think it's possible to write a C++ program that provably doesn't leak. You could define a custom operator new for every type which ensures that it gets allocated with some smart pointer or GC heap.

You could probably still use most of the C++ standard library that returns something needing manual de-allocation (except perhaps new and the old C malloc itself, which can be banned in various ways).

JoeAltmaier• 15 years ago

Virtually disappear. I haven't had a significant memory leak issue for years, and I program almost exclusively in C++.

Scoff if you like, but consider you may not know everything there is to be learned about the craft.

tszming• 15 years ago

I believe most people are actually complaining "threads are hard to use", evil is just a possible outcome if they are used by incompetent programmers.

damienkatz• 15 years ago

Right, it's never been either/or, they can be used to together. Several years ago I implemented libevent support at mysql using a pool of threads, allowing an order of magnitude more client processing. And for many years prior Microsoft had APIs and examples supporting similar operations on Windows.

carbonica• 15 years ago

Russ is pretty much describing Go as it existed in its developer's minds in 2007. He even explains nearly all of Go's (future) interesting features - with nearly identical syntax - before he even gets to an example.

voyou• 15 years ago

Well, actually he's describing Alef as it existed in the Plan 9 system in the early 90s. The creators of Go were also involved in creating Plan 9, so presumably they drew on their earlier experience of channels in Plan 9 when they developed the concurrency system for Go.

dlsspy• 15 years ago

Go existed in various forms for a very long time. I was learning alef in the mid-nineties. When go came out, it was pretty easy to recognize.

That was a great explanation, though.

lcargill99• 15 years ago

Threads tend to be event driven anyway. If one used, say ObjecTime back in the Olden Days, one could actually configure which FSMs had their own O/S thread and which were shared on a single thread.

This being said, event-driven as a design choice has much to recommend it.

jrockway• 15 years ago

No, threads tend to be:

   while( connection = accept_connection ){
       in_thread_run(handle_connection, connection)
   }

nitrogen• 15 years ago

That is event-driven code. A typical accept_connection only returns after receiving a connection event. The I/O code in handle_connection blocks until the event that data can be read/written. The event handling just happens in the OS instead of in userspace with poll/select/etc.

va1en0k• 15 years ago

I'm not really sure, but it seems like an Erlang execution model (except for single-assigment, to which everything can be, and frequently is, automatically boiled down anyway)

nvictor• 15 years ago

anyone has the talk or video download?

sometimes you just can't get enough from slides...

zokier• 15 years ago

http://mirror.cat-v.org/iwp9/2007/videos/Cox.mov

divtxt• 15 years ago

The important question is: how can humans correctly write concurrent code?

We think of "threads" as one of the options. The thing is that we've mostly been using threads with locks (e.g. Java), and slide #3 points out where we have gone wrong:

  Drawbacks of threads
    ...
  Drawbacks of events
    ...
  Actually drawbacks of locks and top-level select loops!

In fact, it is "locks" that humans have trouble with.

Note the title of the presentation - Threads without Locks - suggesting another option. (as others have noted, this presentation describes Go, and I personally believe this is why Go will do well)

edit: wording, formatting

hannesw• 15 years ago

This is exactly where I want to go with RingoJS: Many threads with private mutable scope, global read-only scope, worker/actor based thread interop, one event loop per thread.

Currently we still have shared mutable state that sometimes requires locking (unless you resort to a functional style of programming): http://hns.github.com/2011/05/12/threads.html

fauigerzigerk5• 15 years ago

In my view, the biggest drawback of the evented approach is that logically sychronous code involving IO becomes very low level spaghetti code. E.g:

  log(write(process(read(source))))

becomes:

  read(source, function(input) {
    write(process(input), function(success) {
      log(success)
    })
  })

FooBarWidget2• 15 years ago

I don't see that as spaghetti code at all, especially when you want to handle other things while the read() or write() is blocked. Callback-style code allows you to see the interleaving of events. If you use threads then the interleaving is non-obvious.

fauigerzigerk5• 15 years ago

I guess if you don't see the interleaving in log(write(process(read(source)))) our mental models are too different to merit further discussion of this aspect.

And of course thread based code can do other things as well during blocking IO - on other threads.

dramaticus33• 15 years ago

use channels, you can make them block so the first loop will wait for logger to finish the logging if you like

    do { 
       source = <- sources // read a source from the sources channel
       if source
           data = read(source)
           process <- data  // send it to the process channel
       else
           process <- nil
    } while source

    fn processor {
        do {
            data = <- process
            result = process(data)
            results <- result
        } while data
    }

    fn writer {
        do {
           data = <- results
           msg = write(data)
           log <- msg
        } while data
    }

    fn logger {
        do {
           msg = <- log
           if msg
                print msg
        } while msg
    }

fauigerzigerk5• 15 years ago

My ideal version would be something like

  parallel for(item in source)
    log(write(process(read(item))))

And let the compiler/runtime figure out how to do that. It could generate something similar to your code for instance.

fauigerzigerk5• 15 years ago

I meant to say "logically sequential" not "logically synchronous".

TeMPOraL• 15 years ago

A small usability note - I looked at the page, seeing no way to do anything with it, I reloaded it ("So little text, so much votes on HN - there must be something there!"), and then - still not knowing what it is - accidentally clicked on the page, which moved me to the next slide... There is no hint there that it's a presentation and you can move forward by clicking on it.

bruceboughton• 15 years ago

It's completely unusable on an iPhone.

dramaticus33• 15 years ago

turn off javascript (I didn't even know it was a slide deck, I have js off (NotScripts extension) in Chrome).

To be fair to Russ, it is his slidedeck from doing his talk, not a publication. It was only the 2nd IWP9, we've got a bit better since then :)

jff• 15 years ago

2nd IWP9 was a good one, though--and I got to meet Dennis :)

yxhuvud• 15 years ago

You can also use the arrow keys.

(and there is a hint that there is more to it, in that it showns the slide # in the bottom right corner)

Why threads vs events is a nonsensical question.

Related Stories