Can single thread do everything that multithread can do?

Question

My 1st Question: As per the title.

I am asking this because I came across a StackExchange question: What can multiple threads do that a single thread cannot?

In one of the solutions given in that link states that whatever multithread can do, it can be done by single thread as well.

However I don't think this is true. My argument is this: When we build a simple chat program with socket programming and run it via the command console. If the chat program is single threaded. The chat program is actually half-duplex. Which means we cannot listen and talk concurrently and each time only a party can talk and the other have to listen. In order for both parties to be able to talk and receive message concurrently, we have to implement it with multithreads.

My 2nd Question: Is my argument correct? Or did I miss out some points here, and therefore a single thread still can do everything multithread does?

Consider that we got chat applications before we got multi-core CPUs, so on a hardware level a single "thread" was used to handle everything - OS, GUI, chat application... — MBender, Nov 27 '15 at 10:20
@Shaamaan In a single-core CPU, will that single threaded chat program work? — user3437460, Nov 27 '15 at 10:21
I have no idea, because I've never written a chat application nor seen how chat applications are implemented. I'm just giving you an example - chat applications worked long before multi-core CPUs were widespread, and a single-core CPU is, at least on a hardware level, a single "thread". — MBender, Nov 27 '15 at 10:22
@Shaamaan I think you got mixed up the between multi-threading and multi-processing. A single processor can have multiple threads. I am asking this on the thread level and we should not deem a single processor as a single thread or its equivalent. — user3437460, Nov 27 '15 at 10:33
"If the chat program is single threaded. The chat program is actually half-duplex" - that's a nonsequitur. Just look into asynchronous programming, in the simplest case the `select` syscall to see how you can easily do several IOs without blocking. — Voo, Nov 27 '15 at 10:48
I see the answer given takes my example and runs with it. A single-core processor is capable of doing one thing at a time only and... you know what? Just read the answer by OznOg. ;) — MBender, Nov 27 '15 at 20:25
As @usr 's response already pointed out, the important point applicable to your chat application example are *hardware interrupts*. In your chat application example, the network card will raise an interrupt whenever an incoming data packet arrives. The hardware interrupt will make the CPU stop whatever task it is executing and jump into an OS interrupt handler. This handler will typically read from a buffer the incoming data packet and pass it to the destination app. Once the interrupt is handled, the original task execution will continue at the point where it was interrupted. (continued...) — BlueStrat, Nov 28 '15 at 01:04
(continues...) This interleaved execution that the interrupt mechanism offers is very powerful, and allows you to program with a single-thread mindset and yet be able to handle asynchronous events. I do believe that as long as there is enough CPU power available to complete a task in the expected amount of time, a single threaded application can do everything a multi-threaded application can. — BlueStrat, Nov 28 '15 at 01:10

OznOg · Answer 1 · 2015-12-04T16:31:05.833

4

Let's consider the computer as a whole, and more precisely that you chat application is bound with the kernel (or the whole os) as a piece we would call "the software".

Now consider that this "software" runs on a single core (say a i386).

Then you can figure out that, even if you wrote your chat application using threads (which is probably quite overkill), the software as a whole runs on a single CPU core, which means that at a very moment it performs one single thing even if there seem to be parallel things happening.

This is nothing more but a Turing machine (using a single tape) https://en.wikipedia.org/wiki/Turing_machine

The parallelism is an illusion caused by the kernel because it can switch between task fast enough. Just like a film seems to be continuous picture on screen, when actually there are just 24 images per seconds, and this is enough to fool our brain.

So I would say that anything a multithreaded program does, a single threaded could do.

Nevertheless, now we all use multi-core CPUs which can be seen at a certain point as running on multiple computers at the same time (parallel computing), thus you can probably find software that works on multi core and that would not run on a single threaded one. A good example are device drivers (in kernel). If you have a poor implementation, on non preemptive kernel, you can create a busy loop that waits for an event indefinitely. This usually deadlock on single core (you prevent the kernel to schedule to another task, thus you prevent the event to be sent). But this can work on multi core as the event is usually eventually sent by the other thread running on an other core (hopefully).

edited Dec 04 '15 at 16:31

answered Nov 27 '15 at 10:33

OznOg

4,440
2
26
35

Hmm, so can single thread do everything that multithread can do? – user3437460 Nov 27 '15 at 10:35
@user3437460 As long as the "everything" does not contain fully utilise the possibilities of a multithreaded/multiprocessor system. (A chat program don't do that.) – mg30rg Nov 27 '15 at 10:45
added some precisions, always hard to answer from a general standpoint and address all corner cases. I hope I'm clear enough... – OznOg Nov 27 '15 at 10:51
1

@mg30rg That doesn't make any sense. Sure, even if everything fully utilizes the possibilities of a multithreaded/multprocessor system, because the possibilities are the same. The reason we use multithreaded/multiprocessor systems is because they can provide higher performance with comparable technology. Not because they make possible things that are fundamentally impossible for single-threaded, single-processor machines to do. – David Schwartz Nov 27 '15 at 20:58
@DavidSchwartz What I was referring to is that multithreading enables you to write faster applications, because you can distribute code parts between processors/cores. That is the only thing which can't be done with a single threaded program. – mg30rg Nov 28 '15 at 22:00
@mg30rg When you say "write faster applications", you mean for given hardware. But this question is about what is fundamentally possible, not what you can get out of some particular piece of hardware. – David Schwartz Nov 29 '15 at 18:24
@DavidSchwartz When I was saying _"write faster applications"_, I was explaining my former answer. Multithreading is a way to more completely utilize the possibilities of certain hardware, therefore this (_more completely utilizing the possibilities of certain hardware_) is the thing that can be done by multithreading while can't be done by single threading. This is what I was telling from the very beginning and I'm quite sure you understood it the first time but wished to **bicker** for some reason. – mg30rg Nov 30 '15 at 08:38
@mg30rg I understand it, it's just not correct. It's as silly as arguing that a multi-threaded program can't do everything a single-threaded program can do because it can't create two threads. It totally fails to understand that the question is about fundamental capabilities, not behavior on specific hardware. – David Schwartz Nov 30 '15 at 09:53
@DavidSchwartz The question was: Can or can't a multithreaded program do something a single threaded can't. My answer was _"A single threaded program **can** do everything that multithread can do **except for** fully utilising the possibilities of a multithreaded/multiprocessor system."_ Since my answer was fully correct, what you are doing is scoffing. – mg30rg Nov 30 '15 at 10:01
@mg30rg You could just as well say "A multithreaded program can do something a single-threaded program can't do, it can run on a system that doesn't support single-threaded programs." Or even sillier, "It can work with a library that requires an initialization routine called from a different thread from the one that calls it later." The question makes no sense if you interpret it such that your answer makes sense. It only makes sense if you interpret it in terms of fundamental capability, not behavior in situations that artificially limit one or the other type of process. – David Schwartz Nov 30 '15 at 10:06
@DavidSchwartz We both know that you are simply not right, that is why you are desperately trying to depart from the subject. Answer me in a one word sentence is **"A single threaded program can do everything that multithread can do except for fully utilising the possibilities of a multithreaded/multiprocessor system."** right or not. If it is, than stop harassing me if it is not, just point out why is it not right! – mg30rg Nov 30 '15 at 10:37
It's not right because a single threaded program also can't access a library that requires two threads to access it. If you're allowed to count platform limitations that apply to one solution or the other, all such platform limitations imaginable are answers to the question. The question is incoherent unless you understand it as referring to fundamental limitations, not limitations specific to implementations or platforms. – David Schwartz Nov 30 '15 at 10:39
@DavidSchwartz My differentiation makes sense because it works on the abstraction level of the program, while yours does not make sense because it works on the abstraction level of the elements of the program. You are still desperately trying to change the subject because you can't prove me wrong. – mg30rg Nov 30 '15 at 11:06

score 2 · Answer 2 · answered Nov 27 '15 at 20:48

I want to amend the existing answer (+1):

You absolutely can run multiple parallel IOs on a single thread. An IO is nothing more but a kernel data structure. When you start the IO the OS talks to the hardware and tells it to do something. Then, the CPU is free to do whatever it wants. The hardware calls back into the OS when it's done. It issues an interrupt which hijacks a CPU core to process the completion notification.

This is called async IO and all OS'es provide it.

In fact this is how socket programs with many connections run. They use async IO to multiplex high amounts of connections onto a small pool of threads.

+1 for mentioning hardware interrupts. This is a key aspect that is very applicable to the doubt regarding how a chat application can work on a single-threaded environment. — BlueStrat, Nov 28 '15 at 01:12

score 1 · Answer 3 · answered Nov 27 '15 at 20:55

The core reason why this argument is incorrect is subtle. While it's true that with only a single thread, or single core, or single network interface, that particular component can only be handling a send or a receive at any given time, if it's not the critical path, it does not make sense to describe the overall system as half duplex.

Consider a network link that is full-duplex and takes 1ms to move a chunk of data from one end to the other. Now imagine we have a device that puts data on the link or removes data from the link but cannot do both at the same time. So long as it takes much less than 1ms to process a send or a receive, this single file path that data in both directions must go through does not somehow make the link half-duplex. There will still be data moving in both directions at the same time.

In any realistic chat application, the CPU will not be the limiting factor. So it's inability to do more than one thing at a time can't make the system half-duplex. There can still be data moving in both directions at the same time.

For a typical chat application under typical load, the behavior of the system will not be significantly different whether implementation uses a single thread or has multiple threads with infinite CPU resources. The CPU just won't be the limiting factor.

Can single thread do everything that multithread can do?

3 Answers3