OSDev.org

The Place to Start for Operating System Developers
It is currently Fri Mar 29, 2024 4:56 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: Suspend method execution and resume later
PostPosted: Fri Apr 07, 2017 4:02 pm 
Offline

Joined: Fri Apr 07, 2017 3:45 pm
Posts: 6
Hey there,

I have a different idea of how to implement threads in my os. Instead of switching the context, I'd like to have them in a thread queue:
Code:
while( true ) {
    if( thread = get_next_thread_from_queue() ) {
        thread.make_action()
    }
}


The threads might end some time, thats ok. Otherwise, I'd like to suspend them after some time and push them back to queue. I know, how to safe the stack, but I actually have no idea, how to suspend them. I think it shoud be something like:

Code:
while( running ) {
    if( thread = get_next_thread_from_queue() ) {
        if( !first_run(thread) ) {
            restore_stack(thread)
        }
        thread.make_action()
        // Problem: How to jump from inside thread.make_action to here, after some fixed time?
        safe_stack(thread)
        if( !finished(thread) ) {
            push_to_queue(thread)
        }
    }
}


My problem is: how to interrupt the execution of thread.make_action() and return to the loop? The problem is not, how to measure the time.
Can you give me some buzzwords?

Thank you!


Top
 Profile  
 
 Post subject: Re: Suspend method execution and resume later
PostPosted: Fri Apr 07, 2017 4:11 pm 
Offline
Member
Member

Joined: Mon Feb 02, 2015 7:11 pm
Posts: 898
To interrupt your thread... use an interrupt! A timer interrupt seems most appropriate here.

_________________
https://github.com/kiznit/rainbow-os


Top
 Profile  
 
 Post subject: Re: Suspend method execution and resume later
PostPosted: Fri Apr 07, 2017 4:18 pm 
Offline

Joined: Fri Apr 07, 2017 3:45 pm
Posts: 6
Thanks, but thats not the problem. How to get to the loop, after that interrupt?


Top
 Profile  
 
 Post subject: Re: Suspend method execution and resume later
PostPosted: Sat Apr 08, 2017 7:43 am 
Offline
Member
Member
User avatar

Joined: Thu Jul 12, 2012 7:29 am
Posts: 723
Location: Tallinn, Estonia
maco wrote:
Thanks, but thats not the problem. How to get to the loop, after that interrupt?


By jumping to a well-known point, see setjmp/longjmp.

You should also read up on coroutines, protothreads and similar cooperative threading facilities first.

_________________
Learn to read.


Top
 Profile  
 
 Post subject: Re: Suspend method execution and resume later
PostPosted: Sat Apr 08, 2017 9:57 am 
Offline
Member
Member

Joined: Tue Nov 08, 2011 11:35 am
Posts: 453
maco wrote:
Thanks, but thats not the problem. How to get to the loop, after that interrupt?

Properly implemented interrupt handler saves the state of interrupted task and restores it after finishing its (handler's) work, so interrupted code doesn't notice anything (except the passed time).


Top
 Profile  
 
 Post subject: Re: Suspend method execution and resume later
PostPosted: Sat Apr 08, 2017 10:51 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
What you are describing is... uh, threads. this is exactly how most userland cooperative thread systems work.

Switching from one thread to another does require a switch in context, regardless - that's what threads are, the contexts of sequences of execution.

Note that a process abstraction represents a context for managing the multiplexing of resources, and consists of a set of resources allocated to the process (e.g., memory) to operate on. Between threads, sharing resources has to be moderated by the OS; within a process, all resources are at the disposal of everything else in the process, and the process has the responsibility of managing their use. If a process only uses a fixed amount of resources and never communicates with other processes (rare, but not impossible), then the state of the process is the states of its threads and its resources, nothing else.

A thread, on the other hand, is an abstraction representing the context of the execution of a set of operations (things like the condition of the registers and the stack at a given point in time). Threads exist within the context of a process. Every running process has at least one thread, even if it isn't formally defined as such and there is no existing provision for multiple local threads.

Switching between processes necessarily involves suspending all of the process's threads, but suspending a thread doesn't mean suspending the rest of the threads of a process (unless you use something like the Global Interpreter Lock in Python - something which is generally considered a Bad Idea).

Now, there are a number of ways that the context of a thread - or of a process as a whole - can be suspended. The first, which is pretty much necessary in any any multitasking system, is for the thread to cede control voluntarily, whether to permit other threads to operate, or to wait for some time period (sleep()), to wait for some operation to complete (wait()), or wait for a message from another thread/process (through whatever the IPC primitives being used are). In a cooperative multitasking system, the OS requires threads to voluntarily cede the processor frequently, and some systems (e.g., Oberon) require that compilers and interpreters insert sleep()s into the code automatically to ensure this.

The other major way is when processing an interrupt. Most multitasking systems will reschedule whenever an interrupt occurs, and preemptive multitasking systems use a timer (either with a regular 'tick' or by setting a new timer interrupt cycle each time a scheduling event occurs) to force reschedules periodically. Most OS kernels schedule process this way, but then leave the scheduling of threads to the processes themselves, though most OSes today have a standard threading library which the kernel scheduler is aware of and can work together with.

Some operating systems also provide 'kernel-scheduled threads', which are scheduled independently of each other by the kernel scheduler, and can even run on different CPUs in a multiprocessor platform, while still remaining within the same process context. They are generally more 'heavyweight' than process-local threads, but less so than separate processes.

However, most thread libraries schedule threads locally within a process - meaning that they provide concurrency (more than one thread running multiplexed over a period of time) but not true parallelism (more than one thread running simultaneously), which would require kernel intervention. There is some gray area on this, as it is possible for a process to be assigned multiple CPUs (or multiple independent time slices on different CPUs, depending on how the OS abstracts it) as 'resources' for its exclusive use, which it could then schedule locally, but AFAICT most stock OSes don't support that per se - it is usually only found on systems which are written (or at least tuned) for massively parallel hardware, especially ones designed for massive simultaneous vector processing operations.

Many threading libraries are based on cooperative scheduling, and count on the fact that most threads are I/O bound to allow them to balance the thread operations - compute-bound threads would be expected to cede frequently. Most libraries do have provisions for preemption, though, and the easiest way to provide that in the absence of kernel threading is for the scheduler itself to request that the kernel send a message after a given interval and have the scheduler sleep until either the current thread cedes or the timer message comes in. There are a lot of variations on this, but that's more or less how it is done as a rule.

Does this help, and if not, can you explain your ideas in depth a little more?

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Suspend method execution and resume later
PostPosted: Sat Apr 08, 2017 10:50 pm 
Offline
Member
Member
User avatar

Joined: Sun Sep 19, 2010 10:05 pm
Posts: 1074
Buzzwords:

Interrupt: Any hardware attached to the machine needs to be able to notify the system that an event has occurred. For instance, if you set your timer to 20ms, then it will tell the CPU to stop the currently running code and execute the timer interrupt handler every 20ms. Software can also execute an interrupt handler, as well.

Thread: If your timer interrupt handler decides to switch from one thread to another, it will save the state of the thread that was executing before the timer interrupt occurred, and load the state of the next thread, and continue execution on that thread.

Yield: Software that has no more work to do, or that is waiting for data from the network of hard drive can give up the CPU to the system, instead of waiting for timer interrupt handler to execute.

Coroutine: Instead of a routine starting at the beginning and running until it reaches an exit point, possibly returning a single value, coroutines can return multiple values. On the first call, the routine returns the first value, and the state of the routine (similar to the state of a thread). If the caller wants the next value, it can use the saved state of the routine to resume execution inside the method, which can return another result, or it can set a flag that notifies the caller that there are no more values to return.

If you want to use coroutines in C or C++, you'll need to use a library. As far as I know, coroutines are not supported in the language itself.

_________________
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott


Top
 Profile  
 
 Post subject: Re: Suspend method execution and resume later
PostPosted: Mon Apr 10, 2017 3:06 am 
Offline

Joined: Fri Apr 07, 2017 3:45 pm
Posts: 6
Thank you all for your replies. I will answer them, as far as I'm at home :)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: DotBot [Bot], Google [Bot] and 122 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group