how much memory does a thread in linux take up, if you exclude the
stack size of the threaed. And what is the default thread stack size?

As to the other part of your question: What are you referring to,
virtual address space? Physical memory used by the kernel? Both?

I was watching this intro about Erlang, in which he states that Erlang
has native and super lightweight threads. Erlang threads takes up about
300-350 bytes. This could make it possible to run 1 million threads at
the same time, on the correct hardware. It was mentioned a processor
called Tilera, Tile64, which is a "network chip", which means it could
possibly scale to 1 million cores (across a number of processors) in the
future.

So my question was then, what has to be done with Linux to be able to
operate on such a system? or would it not even be possible with the
current linux architecture

Could you explain why you think so? Because I am pretty sure there are
more ways than the one, or perhaps two ways that are traditional today,
to do high performance computing. Maybe you dont know of those ways yet?

If you had that many cores, you would not want them running threads.
That would make no sense at all.

You wouldn't use threads in that case, at least not in the sense of
the types of threads that Linux creates. If you had a million cores,
in any forseeable architecture within the next several dozen years or
so, you would not want SMP.

Thats only a problem if you use the SharedMemoryconcurrency model.

If you use the Message Passing concurrency model or other non-shared
data models, then synchronisation is no longer an issue. Because if you
don't share the access to the data, you don't need to a use lock, nor
synchronisation.

This is age old knowledge, which was implemented into the Erlang
language 20 years ago. But for some reason computer people insist on
using the SharedMemory model instead. I think its because the Message
Passing model requires a complete shift in the thinking of how we
program our code. And as the optimists we humans are, we think we know
better. So we think that we can solve the SharedMemory model and hence
focus our efforts there. Thats like trying to save a sinking ship.
But I digress.

So back to my question: how much kernel memory does a thread require?

Right, so it would make sense to ask this question about threads that
use that model, but these don't.

I think you misunderstand. shared memory is not the same as the Shared
Memory concurrency model. Yes, the threads share the same memory space,
but that does not mean it have to share the data using that shared
memory. The program can still pass data as messages, using pipes or
other messaging software.

But as I say, it requires a leap in thinking
because of the fact that the structure of the program has to be
completely different than it is for today's sequential program structure.

Three very important aspects of this are:

1) The programs or components are not allowed to use global variables or
memory, just local variables and data structures
2) every piece of the program defined as an independent component has to
communicate its data to the next component by way of a message with
data, instead of by sending a pointer to the data. This means data will
be copied more than normally, but with proper support in the operating
system and a million cores, or even just 256 cores, you wont know the
difference.
3) The programmer has to study the data and the processing to determine
a way to parallelise the execution so it can leverage the number of
threads and cores.

Jan Helgesen <s... at (no spam) nospam.com> writes:

Thats only a problem if you use the Shared Memory concurrency model.
If you use the Message Passing concurrency model or other non-shared
data models, then synchronisation is no longer an issue. Because if
you don't share the access to the data, you don't need to a use lock,
nor synchronisation.

This is nonsense. 'Synchronization' is always (and only) an issue,
when shared ressources are used in potentially conflicting ways, for
instance, to provide communication channels with more than one sender
and one receiver (n:m access, n * m != 0 && (n > 1 || m > 1), please
note that negative numbers of senders or receivers make no
sense). And try to attend to an introductory course on
lingustic. Using a nonsense definitions ('message passing' is only and
exactly what our code does) is ok for marketing, but not for science.

Threads all share a vm. If you ran a million cores with a million
threads, anything that changed the vm would require coordination among
all the threads. That would be a pretty hideous synchronization
bottleneck.

On Oct 6, 1:12 am, Jan Helgesen <s... at (no spam) nospam.com> wrote:

Thats only a problem if you use the SharedMemoryconcurrency model.

Right, which these threads do.

If you use the Message Passing concurrency model or other non-shared
data models, then synchronisation is no longer an issue. Because if you
don't share the access to the data, you don't need to a use lock, nor
synchronisation.

Right, so it would make sense to ask this question about threads that
use that model, but these don't.

David Schwartz wrote:
Threads all share a vm. If you ran a million cores with a million
threads, anything that changed the vm would require coordination among
all the threads. That would be a pretty hideous synchronization
bottleneck.

Thats only a problem if you use the Shared Memory concurrency model.
If you use the Message Passing concurrency model or other non-shared
data models, then synchronisation is no longer an issue. Because if
you don't share the access to the data, you don't need to a use lock,
nor synchronisation.

If you used shared memory threads though, any sensible implementation
would implement the message passing in shared memory. If threads share
memory, that shared memory will almost always be the fastest IPC
mechanism.

If you used shared memory threads though, any sensible implementation
would implement the message passing in shared memory. If threads share
memory, that shared memory will almost always be the fastest IPC
mechanism.

On Oct 6, 2:44 am, Rainer Weikusat <rweiku... at (no spam) mssgmbh.com> wrote:
Jan Helgesen <s... at (no spam) nospam.com> writes:
Thats only a problem if you use the Shared Memory concurrency model.
If you use the Message Passing concurrency model or other non-shared
data models, then synchronisation is no longer an issue. Because if
you don't share the access to the data, you don't need to a use lock,
nor synchronisation.

This is nonsense. 'Synchronization' is always (and only) an issue,
when shared ressources are used in potentially conflicting ways, for
instance, to provide communication channels with more than one sender
and one receiver (n:m access, n * m != 0 && (n > 1 || m > 1), please
note that negative numbers of senders or receivers make no
sense). And try to attend to an introductory course on
lingustic. Using a nonsense definitions ('message passing' is only and
exactly what our code does) is ok for marketing, but not for science.

He is trying to repeat something he doesn't fully understand.

What he wants to say is this:

If you do all your synchronization using message passing, you scale to
more execution vehicles than can reasonably be put in an SMP domain
because you don't have to share an entire vm. Synchronization will be
a bit more expensive than with a shared-memory system, but (hopefully)
there will be so much less synchronization that it will be a net
win.