A legacy embedded system is implemented using a cooperative multi-tasking scheduler.
The system essentially works along the following lines:
Task A does work
When Task A is done, it yields the processor.
Task B gets the processor and does work.
Task B yields
...
Task n yields
Task A gets scheduled and does work
One big Circular Queue: A -> B -> C -> ... -> n -> A
We are porting the system to a new platform and want to minimize system redesign.
Is there a way to implement that type of cooperative multi-tasking in vxWorks?
While VxWorks is a priority based OS, it is possible to implement this type of cooperative multi-tasking.
Simply put all the tasks at the same priority.
In your code, where you do your yield, simply insert a 'taskDelay(0);'
Note that you have to make sure the kernel time slicing is disabled (kernelTimeSlice(0)).
All tasks at the same priority are in a Queue. When a task yields, it gets put at the end of the queue. This would implement the type of algorithm described.
I once worked on a relatively large embedded product which did this. Time slicing was disabled and threads would explicitly taskDelay when they wanted to allow another thread to run.
I have to conclude: disabling vxWorks slicing leads to madness. Avoid it, if it is within your power to do so.
Because tasks were entirely non-preemptive (and interrupt handlers were only allowed to enqueue a message for a regular task to consume), the system had dispensed with any sort of locking for any of its data structures. Tasks were expected to only release the scheduler to another task if all data structures were consistent.
Over time the original programmers moved on and were replaced by fresh developers to maintain and extend the product. As it grew more features the system as a whole became less responsive. When faced with a task which took too long the new developers would take the straightforward solution: insert taskDelay in the middle. Sometimes this was fine, and sometimes it wasn't...
Disabling task slicing effectively makes every task in your system into a dependency on every other task. If you have more than three tasks, or you even think you might eventually have more than three tasks, you really need to construct the system to allow for it.
This isn't specific to VxWorks, but the system you have described is a variant of Round Robin Scheduling (I'm assuming you are using priority queues, otherwise it is just Round Robin Scheduling).
The wiki article provides a bit of background and then you could go from there.
Good Luck
What you describe is essentially:
void scheduler()
{
while (1)
{
int st = microseconds();
a();
b();
c();
sleep(microseconds() - st);
}
}
However if you don't already have a scheduler, now is a good time to implement one. In the simplest case, each entry point can be either multiply inherited from a Task class, or implement a Task interface (depending on the language).
you can make all the tasks of same priority and use task delay(0) or you can use tasklock and taskunlock inside your low priority tasks where you need to make non-premptive working.
Related
Sorry I cannot post proprietary codes here. Basically, it's a Mac GUI application. The codes were not properly designed to make use of the asynchronousity concept. Everything is processed on the main thread, and it's impossible to change the design overnight. Therefore, I'd like not to go with the dispatch_async(…) solution.
The context of the problem is: I have a time-consuming task that runs on the main thread. While the task is being processed, I try to update/redraw a progress bar (NSProgressIndicator) based on the task's completion percentage (from 0% to 100%). However, because the task runs on the main thread, the main thread is blocked, and any update/redraw event in the event queue has to wait until the main thread has a chance to look at it, so the progress bar is not updated/redrawn at all during the task execution.
The solution I'm thinking about is to create another app (with an .exe file) that handles the progress bar drawing. From the main app, I'll create another process and have that process execute the other app. The task's completion percentage can be sent from the main app to the other app by using the Boost inter-process message queue.
I'm hoping to hear about both advantages and disadvantages of this solution, so any thoughts will be much appreciated!
You can do that from a thread in the same process as well. Interprocess message queues still work, though any threadsafe solution would suffice.
In general, it can be worth running some non-trivial tasks out-of-process. The kernel-level process-isolation has benefits that threads can never have:
memory space separation (security)
privilege separation (the other process can potentially run in a different security context)
Therefore when dealing with untrusted inputs or unreliable third-party library code you can gain stability guarantees for the main process.
However for your purposes it sounds like severe overkill.
I wonder how create a CSP library for obj-c, that work like Go's channels/goroutines but with idiomatic obj-c (and less boilerplate than actual ways).
In other languages with native courutines and/or generators is possible to model it easily, but I don't grasp how do the same with the several ways of do concurrent programing in obj-c (plus, the idea is have "cheap" threads).
Any hint about what I need to do?
I would look at the State Threads library as it implements roughly the same idea which underlies the goroutine switching algorythm of Go: a goroutine surrenders control to the scheduler when it's about to sleep in a syscall, and so the ST library wraps OS-level file descriptors to provide their own FD-like objects which can be read from (and/or written to) but instead of blocking the whole process these operation transfer control to other light-weight threads managed by the library.
Then you might need a scheduler more advanced than that of the ST library to keep OS threads busy running your SPs. A no-brainer introduction to the Go 1.2 scheduler is here, and it contains a link to a more hard-core design document. The rest is in the Go's source code.
See also this answer on SO.
Create operations, e.g. for an example consider this process:
process x takes number from east, transforms it to a string, and gives it to west.
That I could model it with an object that keeps an internal state of x (consisting of number and string) and the following operations:
east-output, operation defined somewhere else by east process logic
x-input, operation that depends on east-output. It copies number from east-output's data structure into x's data structure
x-output, operation that depends on x-input. Its content is defined as purely internal transformation - in our example, stringWithFormat...
west-input, operation that depends on x-output, etc.
Then you dump the operations into NSOperationQueue and see what happens (does it work, or are there contradicting dependencies...)
We have one task who State is Ready+I . Can we find which task is it waiting for to release all semaphores? This is pre-6.0 vxworks
If you can get a backtrace from the task, you should see it blocked on some kind of system entity, e.g., a semaphore. You can look at the arg list printed in the backtrace, and then use semShow from the C shell to get information about that semaphore. Other system synchronization entities offer similar *Show routines.
Presuming that the entity supports the concept of an "owner", semShow should display the TID of the owner.
Under the older, Tornado-based systems, the WindView tool will allow you to see the relationship between tasks over time. WindView can show all your task state transitions, interrupts, semaphore operations, etc.
For newer, Workbench-based systems, the same tool is now called System Viewer.
WindView/System Viewer is the deluxe way to investigate any problem you are having with task states and how they got that way.
If I understand your question, you have a task that is inheriting the priority of some other task and you are having trouble identifying this other task. I don't recall if the i WindSh command prints the inherited priority but if it does that might give you a clue about which of the pended tasks you should look at. Once you've narrowed it down to a couple tasks you should be able to use the tw command to print information on what object a task is pended upon.
On a side note, why are you concerned about priority inheritance? After all priority inheritance isn't a problem, rather it is the solution to priority inversion.
If your task is READY+I, i don't think it is waiting for semaphores anymore. It is waiting to access the CPU. You must have a higher priority task running that is preventing your READY+I task from running.
Or, equivalently, how would you design such an API. Expected/example usage would be illustrative as well.
My curiosity comes directly from the comments (and subsequent editting on my part) of this answer. Similar questions/discussions in the past provide a bit of inspiration to actually asking it.
Executive summary:
I don't feel a multithreaded UI api is possible in a meaningful way, nor particularly desirable. This view seems somewhat contentious and being a (relatively) humble man I'd like to see the error of my ways, if they actually are erroneous.
*Multithreaded is defined pretty loosely in this context, treat** it however makes sense to you.
Since this is pretty free-form, I'll be accepting whichever answer has the most coherent and well supported answer in my opinion; regardless of whether I agree with it.
Answer Accepted
**Ok, perhaps more clarification is necessary.
Pretty much every serious application has more than one thread. At the very least, they'll spin up an additional thread to do some background task in response to a UI event.
I do not consider this a multithreaded UI.
All the UI work is being done on single thread still. I'd say, at a basic level, a multithreaded UI api would have to do away with (in some way) thread based ownership of UI objects or dispatching events to a single thread.
Remeber, this is about the UI api itself; not the applications that makes use of it.
I don't see how a multithreaded UI API would differ much from existing ones. The major differences would be:
(If using a non-GC'd language like C++) Object lifetimes are tracked by reference-counted pointer wrappers such as std::tr1::shared_ptr. This ensures you don't race with a thread trying to delete an object.
All methods are reentrant, thread-safe, and guaranteed not to block on event callbacks (therefore, event callbacks shall not be invoked while holding locks)
A total order on locks would need to be specified; for example, the implementation of a method on a control would only be allowed to invoke methods on child controls, except by scheduling an asynchronous callback to run later or on another thread.
With those two changes, you can apply this to almost any GUI framework you like. There's not really a need for massive changes; however, the additional locking overhead will slow it down, and the restrictions on lock ordering will make designing custom controls somewhat more complex.
Since this usually is a lot more trouble than it's worth, most GUI frameworks strike a middle ground; UI objects can generally only be manipulated from the UI thread (some systems, such as win32, allow there to be multiple UI threads with seperate UI objects), and to communicate between threads there is a threadsafe method to schedule a callback to be invoked on the UI thread.
Most GUI's are multithreaded, at least in the sense that the GUI is running in a separate thread from the rest of the application, and often one more thread for an event handler. This has the obvious benefit of complicated backend work and synchronous IO not bringing the GUI to a screeching halt, and vice versa.
Adding more threads tends to be a proposition of diminishing returns, unless you're handling things like multi-touch or multi-user. However, most multi-touch input seems to be handled threaded at the driver level, so there's usually no need for it at the GUI level. For the most part you only need 1:1 thread to user ratio plus some constant number depending on what exactly you're doing.
For example, pre-caching threads are popular. The thread can burn any extra CPU cycles doing predictive caching, to make things run faster in general. Animation threads... If you have intensive animations, but you want to maintain responsiveness you can put the animation in a lower priority thread than the rest of the UI. Event handler threads are also popular, as mentioned above, but are usually provided transparently to the users of the framework.
So there are definitely uses for threads, but there's no point in spawning large numbers of threads for a GUI. However, if you were writing your own GUI framework you would definitely have to implement it using a threaded model.
There is nothing wrong with, nor particularly special about multithreaded ui apps. All you need is some sort of synchronization between threads and a way to update the ui across thread boundaries (BeginInvoke in C#, SendMessage in a plain Win32 app, etc).
As for uses, pretty much everything you see is multithreaded, from Internet Browsers (they have background threads downloading files while a main thread is taking care of displaying the parts downloaded - again, making use of heavy synchronization) to Office apps (the save function in Microsoft Office comes to mind) to games (good luck finding a single threaded big name game). In fact the C# WinForms UI spawns a new thread for the UI out of the box!
What specifically do you think is not desirable or hard to implement about it?
I don't see any benifit really. Let's say the average app has 3 primary goals:
Rendering
User input / event handlers
Number crunching / Network / Disk / Etc
Dividing these into one thread each(several for #3) would be pretty logical and I would call #1 and #2 UI.
You could say that #1 is already multithreaded and divided on tons of shader-processors on the GPU. I don't know if adding more threads on the CPU would help really. (at least if you are using standard shaders, IIRC some software ray tracers and other CGI renderers use several threads - but i would put such applications under #3)
The user input metods, #2, should only be really really short, and invoke stuff from #3 if more time is needed, that adding more threads here wouldn't be of any use.
What's the difference between a monitor and a lock?
If a lock is simply an implementation of mutual exclusion, then is a monitor simply a way of making use of the waiting time inbetween method executions?
A good explanation would be really helpful thanks....
regards
For example in C# .NET a lock statement is equivalent to:
Monitor.Enter(object);
try
{
// Your code here...
}
finally
{
Monitor.Exit(object);
}
However, keep in mind that Monitor can also Wait() and Pulse(), which are often useful in complex multithreading situations.
Edit:
In later versions of the .NET framework, this was changed to:
bool lockTaken = false;
try
{
Monitor.Enter(object, ref lockTaken);
// Your code here...
}
finally
{
if (lockTaken)
{
Monitor.Exit(object);
}
}
They're related. For example, in C# the lock statement is a simple try-finally wrapper around entering a Monitor and exiting one when done.
Monitors are compiler-assisted "semi-automatic" locks. They allow one to declare synchronized methods on classes, etc. This is just a different approach to providing mutual exclusion. I found this book to be the most thorough explanation of the concepts, even though it's mostly geared towards OS developers.
A lock ensures mutual exclusion.
A monitor associates the data to be protected and the mutual exclusion and synchronization primitives required to protect accesses to the data.
Synchronization is used e.g. when you need one thread to wait until an event occurs (e.g., wait until another thread places an item in a queue).
Monitors is a programming-language construct that does the same thing as semiphores/locks, but Monitors control the shared data by synchronizing at run time. In contrast, locks protect the shared data by just "spinning" which can lead to poor CPU utilization.
There is no difference, lock generates Monitor.Enter and Monitor.Exit within a try/finally block. Using Monitor over lock allows you to fine tune because it has Pulse and PulseAll. You can also have alternate processing should you be unable to acquire the lock with TryEnter.
Monitor is the concept and Lock is the actual implementation.
As far as I have researched so far, monitor is a set of principles for thread synchronization, while locks are, along with "thread cooperation" facilities like wait and notify, the way monitors are implemented in Java. So effectively, if we try to form the exact relationship between the two notions, locks are one part of the implementation of monitors (the other being wait and notify mechanisms). Please correct me if I'm wrong, but I would really appreciate if the correction is very specific.
Lock focus on only mutual exculsion, but
Moniter provides mutual exclusion automatically.
So we don't need to worry of using mutual exclusion in Monitor.
Instead of ME, we need to consern of sycronzing only when we do programming.
Moniter provides more systematical way of programming.
It, therefor, is more advanced one.