CODEWITHSUNDEEP
multithreadingprocessoperating-system
sandeep bisht
sandeep bisht

Reputation: 111

How does OS "protects" or "maintains boundaries" for different stacks of different threads within a process?

How does OS "protects" or "maintains boundaries" for different stacks of different threads within a process? I know that individual threads gets stack within process stack but what bothers me how OS prevents other threads from overriding it ?. Any pictorial representation would do a great favour.

Upvotes: 0

Views: 65

Answers (2)

Martin James
Martin James

Reputation: 24857

if two long threads (say 'A' and 'B')are running simultaneously and 'A' calls functions in order a1,a2,a3..and 'B' in order b1,b2,b3 ....then this information have to be saved

The code, ie. binary instruction codes, for the functions 1,2,3 don't change, (unless the code is self-modifying - never do that). The A and B threads, running on different cores, can read the instructions concurrently without any problem and execute them independently. It is far from uncommon for multiple threads to start at the same code address and so perform the same action on different data.

Processor registers are also OK - each core has a different set of registers in hardware & so they cannot 'overwrite' each other. Note that this processor register set includes the stack pointer.

Stack data, eg. return adresses, local variables and parameter blocks, do not overwrite because each thread is allocated its own stack memory space. Threads A and B are running on different cores and so have their own stack pointer pointing at their own stack space.

Threads A and B can therfore call functions 1,2,3 independently and concurrently, running on different cores and, if the functions only use local vars and parameters, nothing extra needs to be saved or protected upon function calls and returns just because two, (or more), threads are running the functions.

Preemption only occurs when triggered by an 'interrupt' - either a system call from a running thread, or a hardware interrupt from a peripheral device that causes a driver to run, that the OS interprets, (using the interrupt parameters, scheduling algorithms and internal state data, in the manner of a state-machine), as a requirement to change the set of running threads.

Essentially, preemption requires the core register set, including the hardware stack-pointer, to be saved in a Thread Control Block in the kernel, (allocated at the time of thread creation). Another thread can be set running instead by restoring the register set from another TCB for another thread. Essentially, the kernel swaps threads by swapping stack pointers - the thread stack data itself does not need to be saved - it just remains in memory until needed again when the preempted thread becomes running again.

This register-set-swapping is fairly easy, (!), on a single-core machine or if the OS decides that that the thread to be preempted is running on the same core that handled the interrupt. If the thread to be preempted is running on another core, the kernel code has to issue a hardware-interrupt to the other core to force the running thread to run an inter-processor comms driver and so enter the kernel to get stopped - a whole new level of nastiness:)

Upvotes: 1

posix
posix

Reputation: 1

different OS have different technique and mostly all move around Synchronization, different thread wait for different resources that's being in use by other thread , until that thread done with that no other thread can take it (matter of fact they lock it ).

its like u and your brother fighting for same cake and your mother told that you will get it after your brother, and gave fridge key to him, so until he's done with that he can keep the lock and ones he done he gave fridge lock to you.

u and u'r brother are different process fighting for resource(cake) in and u cant get lock until other is done.

Upvotes: 0

Related Questions