OSDev.org

bluemoon wrote: Interesting. But would it breaks if I manually push 0xDEADBEEF on stack?

The 3rd solution is a structured exception handler, where unresolved #PF have a last chance to survive by passing to user handler for rescue.
you then mmap in the user handler.

Not necessarily. That's what break syscall good for (known as "sbrk"). If it happens, you can move the whole stack upwards, and modify esp in tss. You can implement it without specific syscall too, the trick is you have to check heap_end==stack_end in PF handler before a page is allocated. The app would not notice at all, and continues without a problem.

So threads of the same process will share code and data, but will have their individual stacks. This is what Solaris call light weight process. In this case the kernel aware of threads, and switches among them by invalidating only the stack (opposite to invalidating the full address space on process switch).

Which is - as I wrote before - complicated, and, hm let's say, more than dangerous. There's a good reason why direct calling of ring3 function from ring0 code is prohibited.

Gigasoft wrote:

So threads of the same process will share code and data, but will have their individual stacks. This is what Solaris call light weight process. In this case the kernel aware of threads, and switches among them by invalidating only the stack (opposite to invalidating the full address space on process switch).

That sounds like an unnecessarily complicated thing to do just to conserve virtual addresses. It's better to just share the same address space between all threads, not to mention less of a surprise to the programmer. People have expectations of what a thread is. If some pointers are always valid, while others sometimes mean this and sometimes that, it does not rhyme with that expectation. That is why you name your thread creation function pthread_create and not pfrankenstein_monster_eatmybrain, for example.

IEEE Std 1003.1 wrote:Thread

A single flow of control within a process. Each thread has its own thread ID, scheduling priority and policy, errno value, thread-specific key/value bindings, and the required system resources to support a flow of control. Anything whose address may be determined by a thread, including but not limited to static variables, storage obtained via malloc(), directly addressable storage obtained through implementation-defined functions, and automatic variables, are accessible to all threads in the same process.

Gigasoft wrote:Accessing a stack variable belonging to another thread is a perfectly legal and normal behaviour.

#define TOTAL_DATA      (10000)
#define NCORES          (4)
#define DATA_PER_CORE   (TOTAL_DATA/NCORES)

int control_func() {

    int     data[TOTAL_DATA];
    int     tid[NCORES];
    int     i;

    for (i=0; i<NCORES; ++i) {
        pthread_create(&tid[i], NULL, work_func, &data[i*DATA_PER_CORE]);
    }

    for (i=0; i<NCORES; ++i) {
        pthread_join(tid[i], NULL);
    }

    for (i=0; i<TOTAL_DATA; ++i) {
        printf("Data %d: %d\n", i, data[i]);
    }

    return 0;
}

void *work_func(void *data) {

    int i;

    for (i=0; i<DATA_PER_CORE; ++i) {
        data[i] = something();
    }

    return NULL;
}

Gigasoft wrote:That sounds like an unnecessarily complicated thing to do just to conserve virtual addresses.

Gigasoft wrote:Accessing a stack variable belonging to another thread is a perfectly legal and normal behaviour

An "application-managed thread stack" is a region of memory allocated by the application-for example, memory returned by the malloc() or mmap() functions-and designated as a stack through the act of passing the address and size of the stack, respectively, as the stackaddr and stacksize arguments to pthread_attr_setstack().
...
The application may thereafter utilize the memory within the stack only within the normal context of stack usage within or properly synchronized with a thread that has been scheduled by the implementation with stack pointer value(s) that are within the range of that stack.

gerryg400 wrote:The Posix spec. doesn't require that a pthread program create its own thread stacks.

As well as the stack, POSIX.1 specifies that various other attributes are distinct for each thread

turdus wrote:

Code: Select all

---------- 4 GB
Kernel                           mapped globally
---------- 3 GB
v Stack v                        mapped per thread
[empty]
^ Heap  ^                        mapped per process
Data                             mapped per process
Code                             mapper per process
---------- 0 GB

So threads of the same process will share code and data, but will have their individual stacks. This is what Solaris call light weight process.

First, you must record your stacks (so bound checks or guard item checks can be and should be done); and second you are only allowed to refer to another thread's stack under special circumstances, which very unlikely called "normal". What's more, every process must have it's own stack-aware scheduler implementation. Now that is what I call "unnecessarily complicated".

The application may thereafter utilize the memory within the stack only within the normal context of stack usage within or properly synchronized with a thread that has been scheduled by the implementation with stack pointer value(s) that are within the range of that stack.