Is true multithreading really necessary?

So yeah, I’m creating a programming language. And the language allows multiple threads. But, all threads are synchronized with a global interpreter lock, which means only one thread is allowed to execute at a time. The only way to get the threads to switch off is to explicitly tell the current thread to wait, which allows another thread to execute.

Parallel processing is of course possible by spawning multiple processes, but the variables and objects in one process cannot be accessed from another. However the language does have a fairly efficient IPC interface for communicating between processes.

My question is: Would there ever be a reason to have multiple, unsynchronized threads within a single process (thus circumventing the GIL)? Why not just put thread.wait() statements in key positions in the program logic (presuming thread.wait() isn’t a CPU hog, of course)?

I understand that certain other languages that use a GIL have processor scheduling issues (cough Python), but they have all been resolved.

You say parallelism is handled by multiple processes, but I would beg to differ. In-process parallelism is, depending on the program, much simpler and faster, due to (universal and by-default) shared memory.

When you don’t have shared memory, you need a lot of extra engineering (like a common server process, with message passing to and fro) to have any shared state outside of what the OS provides for all processes (e.g. the file system). This also implies a lot of overhead for programs with a fair bit of shared state. Yes, you need locking most of the time, provided you don’t have another mechanism (like STM). But in-process locking can be much simpler/faster than IPC, and actually accessing the data is much simpler: You just fricking do it, rather than doing IPC.

You also imply (I’m inferring this from your description of thread.wait) that thread are non-preemptive, i.e. it’s up to each thread when its time slice ends. Two notes on this:

It’s incompatible to some common uses of threads (e.g. running a computation with a timeout, or asynchronously even if it wasn’t built to be async).
It’s unlike the threads in many common languages, so expect newcomers to be confused and expect lots of code that simply doesn’t ever wait.

On the other hand, I rather like the increase in determinism (if the scheduler is deterministic too, certain concurrency bugs ought to be much simpler to reproduce). It’s a trade-off.

Firstly, your question seems confused about the relationship between a GIL and cooperative multithreading. Co-operative multithreading is when the the current thread continues to execute until it gives up execution. The greenlet library for python is based on this model. It simplifies coding in many cases because you don’t have to worry about context switches except at specific points.

A global interpreter lock is a lock which prevents more than one thread from executing code inside the virtual machine at once. Execution will still jump from thread to thread without the thread requesting it. The times that switches will happen is limited (exactly how depends on the language implementation). But you don’t really the simplification that the co-operative multitasking gives you.

Your question actually appears to be asking about whether you can get away with co-operative multitasking with multi-process options. Of course strictly speaking you can still do whatever you want without pre-emptive multithreading, the question is whether it’ll be easier/more efficient with it.

I use co-operative multithreading and process parallelization whenever I can. Most of the time I find that works beautifully and is a simpler approach then would be required if I were to try and use threads. But I think there are some cases where this falls down.

Let’s consider some examples:

1) Worker Thread and UI Thread

Its not uncommon to have a long running task executed in an application while a progress bar is displayed. In order to keep things working we need to execute UI events as well as continue running the task. Normally, we’d have the task executing in a separate thread. But if the threads are co-operative, this won’t work because the task won’t normally have any reason to delay itself.

So what can we do?

In some cases, there were be natural pause points in the long running task. There could be File I/O, database calls, sockets reads. All of these naturally block, and if your language automatically thread waits at these points, many long running tasks may yield naturally.
The task could be moved into another process. But for some tasks, this will take a lot of effort. I may have to ship a lot of data to the subprocess and then let it process and ship the data back.
You could introduce explicit thread yield calls. The disadvantage here is that you are doing something manually that other languages do automatically.

2) Serving many requests

A system such as a database or a web server may need to serve requests coming from many different external systems. In doing so it will have to navigate in-memory data structures and multiple requests may require the same data structures. Typically, we might implement this using multiple threads and using locks on the data structure to make sure nobody changes it while it is being read.

As long as we only have on core operating, co-operative multithreading actually works great. But when you’ve got multiple cores, you can’t take advantage of it that way. You could introduce multiple processes. But the trouble there is that you can’t really share in-memory data structures all that well. I’m sure you can work around it with IPC techniques, but I think it’ll always be awkward compared to the locks model.

I’ve designed a number of languages and come to realize there are different needs for threads or parallelism.

One is raw performance. If a program is CPU-bound and there is a way to parallelize it across multiple cores then clearly one would want that.

The other, and far more common need, in my experience, is to simplify the representation of sequences of activities where those sequences are, in some sense, independent of each other.

The obvious case is listening on multiple input streams and responding to requests on those streams.

A case I work with a lot has to do with pharmacologic modeling, where a subject may get one medication on one schedule, another on another, and have observations on yet another schedule, while simultaneously dealing with adverse events and alarms. Treating this as a purely event-driven process is possible, but the coding is very clumsy.

In these cases, what is needed is a way to clearly express what one is trying to say, and it has little to do with being CPU-bound and needing performance. For these needs, non-preemptive parallelism works better, and is much less prone to race conditions.

Here’s a quick answer – one thread for the UI and one for asynchronous data processing work. So yes, there’s a need for true multi-threading. Massive parallel computations are another obvious answer that you alluded to.

From a broader point of view, why wouldn’t you offer the capability? Many, many devices have multiple cores available to handle processes. Why would you arbitrarily limit the ability of any program written in the language you’re creating?

In a world where CPU’s can have multiple “cores” and each “core” can work on a separate thread then having multiple independent threads can be a useful feature.

In a world where “events” such as data arriving from the network need to be processed “now” and not when another thread says “I’m done for now” then it may be useful to have multiple independent threads.

Is it really “parallel” processing if only one task is being worked on at a time?

The better question is this: why, why are you doing this?

If it’s a domain specific language then you shouldn’t care what we think, you know the domain better.

If it’s a general purpose language, what makes it distinct enough to be recognized among the many already existing (besides adding this limitation)?

If there is no shared mutable state then it makes life a lot simpler because you don’t need to synchronise between processes. At that point you have an actor model as in Erlang.

The other problem you have is that if you are counting on the programmer to call thread.wait() or the like then you have the possibility of a misbehaving program bringing down the whole system.

I would suggest you take a good look at Both Erlang and Clojure as they both have some of the aspects of what you are looking for.

After analyzing other people’s answers, I believe I now understand why simultaneous multithreading is important.

There are two main reasons why a general-purpose language should have real, preemptive multithreading support:

Sometimes developers want to use real threads in their programs. ‘Nuff said.
Real threads are necessary to allow memory to be shared across threads running on multiple processor cores. This feature is essential for performance optimization in some cases, and in other cases it just makes the code easier to write.

However, in cases where memory-sharing is less important, cooperative multithreading programs are just as easy to write and far easier to debug, as long as the developer understands how to use the system.

So the answer is: Yes, true multithreading really is necessary in some cases, but only for certain performance optimizations and accessibility to developers who prefer it. Otherwise, cooperative (“fake”) multithreading is the best solution.

Thanks for all the input guys, I might not have figured this out without you. I’m going to include both threading schemes in my language. We’ll see how well that goes.

these day if you want more speed for calculations you need to go concurrent, especially when you have more cores to use

to give an example: most GUI frameworks have a single thread that manipulates the screen and handles the user events, but the handling of these events must finish quickly or the entire GUI will hang

if you want to do any IO you could use async io and call backs

you language seems to rely on cooperative multithreading which requires all the code in the application to cooperate (or at least don’t block indefinitely), preemptive multithreading is comparatively easier to code for (with greater pitfalls though)

Filed under: softwareengineering - @ 13:07

Thẻ: language-design

Thiết kế website giá rẻ

Danh mục

Is true multithreading really necessary?

1) Worker Thread and UI Thread

2) Serving many requests