Multitasking in BlitzMax

The following is an attempt at a TaskManager that lets you run services "asynchronously" in BlitzMax.

Tasks may be serviced whenever, not just when you call WaitEvent, but when calling any BlitzMax function that causes a PollSystem including KeyDown, WaitEvent and many others.

There is protection built into the TaskManager that will stop services being reentrant so your callback will never be called while its running it's current refresh cycle (see _busy field).

Basically the following creates a multitasking environment where any services (functions) you need to call on a regular basis can be easily added to a tasklist.

Note how the tasks keep printing even when you are dragging the Max2D window, the trick is to never call any Max2D drawing from such tasks as I think this will create a deadlock in Windows. MaxGUI offers more flexibility for graphics rendering where the GADGETPAINT event can be used to synchronize Max2D drawing with the operating systems own expectations / requirements.

Similar to a multithreading environment you need to be careful to cooperate with the main program and any other tasks.

Also, as timers are a limited resource on some systems (16 per Windows app etc.), a single 100hz timer is used by the TaskManager to service all threads.

' blitzmax multitasking example

Strict

Global TaskManager:TTaskManager=New TTaskManager

Function task1()
	Print "task1"
End Function

Function task2()
	Print "task2"
End Function

TaskManager.StartTask 10,task1
TaskManager.StartTask 20,task2

Graphics 640,480

While WaitEvent()
	DebugLog CurrentEvent.toString()
Wend

End

Type TTask
	Field _hertz#
	Field _count
	Field _millis
	Field _ticks
	Field _callback()
	Field _busy

	Method Start(hz#,callback())
		_count=0
		_hertz=hz		
		_millis=MilliSecs()
		_callback=callback
		TaskManager._tasklist.AddFirst Self
	End Method

	Method Stop()
		_hertz=0
		TaskManager._tasklist.Remove Self
	End Method

	Method Update(ms)
		Local	count
		If _busy Or _hertz=0 Return	'ignore if stopped or already in callback 
		_busy=True
		count=((ms-_millis)*_hertz)/1000
		If count>_count
			_ticks:+1
			_count=count
			_callback()
		EndIf
		_busy=False
	End Method

End Type

Type TTaskManager
	Global _tasklist:TList 
	Global _timer:TTimer
	Global _event:TEvent
	
	Method New()
		_tasklist=New TList
		_event=CreateEvent( EVENT_TIMERTICK,Null,0 )
		AddHook EmitEventHook,hook
		_timer=CreateTimer(100,_event)
	End Method

	Function hook:Object( id,data:Object,context:Object )
		Local ms
		Local t:TTask
		If data<>_event Return data
		ms=MilliSecs()
		For t=EachIn _tasklist
			t.Update(ms)
		Next
	End Function

	Method StartTask:TTask( hertz#,callback() )
		Local t:TTask
		t=New TTask
		t.Start hertz,callback
		Return t
	End Method

End Type

Possibly all uses of the word Task should be replaced with Service as it is currently required that each task return from it's callback for the system to continue.

Will add more details after answering initial questions....

yes, you sir at the back -

Looks nice. It runs fine on my system here. I don't entirely understand all of it but I presume, to simplify, it's basically a way of calling given functions at a given time interval using a system timer, as if each function is a `thread` of sorts, as callback functions. So you can do whatever you want from that function and then cooperatively return back to the system. Can I presume this means that until you return from the function, the system is `locked in`? Is the o/s locked-in or just the Blitz application? What happens when the timer says its time for another function to be called, but the one you're in hasn't returned yet because it's doing processing? Does it just skip the call or put it in a queue or something?

It's a nice little system. What I had been doing is check the Millisecs() timer and manually switching functions. So does your system not waste any cpu time when it's waiting for it to be time to trigger the function? ie you have to PollEvent in some way, to give control over to the o/s, to know if there's an event waiting there, otherwise you come back and sit there polling?

I use this
http://www.blitzmax.com/codearcs/codearcs.php?code=1721
I just say at at at what milli delay to call each function, and it sort of mutiltasks

(Ok what a really do is have the one function saying what task gets the time, but its the same principle)

@Skid, dont forget we have a limit of 20timers ;)

H&K, the task manager allows limitless tasks serviced from the single timer.

AD, I've had a bit of a look and it turns out PollSystem does not allow reentrant usage so 1 task can't run above another,

however, a quick squizz at brl.system, and the solution seems to be:

Function task2()
	For Local i=1 To 50
		Delay(10)	'simulate big jobs
		Print "task2"
		Driver.poll
	Next	
	Print "DONE!"	
End Function

If you modify the original code, you will see task 1 being serviced while task2 is chomping through it's loop. However there is no way (short of threading) execution can return to task2 until task1 ends, but it does allow for some useful solutions I think.

That will teach me to read the whole listing ;)
So its more like my solution than I thought ;)

One of either Flame or Dream said that if Bmax was redone with the Newer MiniGW then it would be mutli thread safe. Do you know if this is true?

this is dangerous. the function must run 1000%! otherwise there is a trailer. but it is an alternative.

OK, working on the assumtion that TTaskManager is a singleton.

Remove TaskManager:TTaskManager=New TTaskManager

Add this as a Global of TTaskManager
Global TaskManager:TaskManager=New TaskManager
Change TTaskManager to TaskManager and Change StartTask() into a Function

' blitzmax multitasking example

Strict

TaskManager.StartTask 10,task1
TaskManager.StartTask 20,task2

Graphics 640,480

While WaitEvent()		

	Select EventID()			
	
		Case EVENT_KEYDOWN
			
			If EventData() = KEY_SPACE
				PostEvent( CreateEvent:TEvent (EVENT_APPTERMINATE) )
			EndIf
	
		Case EVENT_APPTERMINATE
		
			End

	End Select

	DebugLog CurrentEvent.ToString()
Wend

End


'=======================================================================


Function task1()
	Print "task1"
End Function

Function task2()
	Print "task2"
End Function


'=======================================================================


Type TTask
	Field _hertz#
	Field _count
	Field _millis
	Field _ticks
	Field _callback()
	Field _busy

	Method Start(hz#,callback())
		_count=0
		_hertz=hz		
		_millis=MilliSecs()
		_callback=callback
		TaskManager._tasklist.AddFirst Self
	End Method

	Method Stop()
		_hertz=0
		TaskManager._tasklist.Remove Self
	End Method

	Method Update(ms)
		Local	Count
		If _busy or _hertz=0 Return	'ignore if stopped or already in callback 
		_busy=True
		Count=((ms-_millis)*_hertz)/1000
		If Count>_count
			_ticks:+1
			_count=Count
			_callback()
		EndIf
		_busy=False
	End Method

End Type

Type TaskManager

	Global TaskManager:TaskManager=New TaskManager
	Global _tasklist:TList 
	Global _timer:TTimer
	Global _event:TEvent
	
	Method New()
		_tasklist=New TList
		_event=CreateEvent( EVENT_TIMERTICK,Null,0 )
		AddHook EmitEventHook,hook
		_timer=CreateTimer(100,_event)
	End Method

	Function hook:Object( id,data:Object,context:Object )
		Local ms
		Local t:TTask
		If data<>_event Return data
		ms=MilliSecs()
		For t=EachIn _tasklist
			t.Update(ms)
		Next
	End Function

	Function StartTask:TTask( hertz#,callback() )
		Local t:TTask
		t=New TTask
		t.Start hertz,callback
		Return t
	End Function

End Type

This way, the initialization of TaskManager is automatic

(Note: Because the original wasnt a singleton, was the reason I felt that Skid should limet the number of TaskManagers to less than 20, however having thought about it, limiting it to one seems a better Idea)

Oh and press space or click on the X to stop the program, (Really Skid ;)

This is cool. But isn't it wasting quite a lot of time waiting for events when it could be processing?

And isn't there some delay between the timer ticking and the event being detected and used, ie it's inaccurate?

Also, does this only run one function at a time or can a shorter function pre-empt a longer one? And if so, isn't there a lot of time being wasted checking if the timeslice is expired or whatever? ie isn't it checking all tasks upon every timer tick, rather than just pre-empting to the highest priority task?

1) Yep, if the processing is shorter than the time allocated for it, the program sits in the event loop

2) Yes ish. If everything is running under spec, then the tick is "accuarate"(ish:- like dont launch anti missile systems from it), however if the eventloop is too long (so the system cannot poll the ticks), or
3) As the ticks arnt pre-emptive, the just stackup oneach other, thus lossing accuracy. Generaly you have to make sure that everything is happening on a tick, so that the eventloop is simply posting/processing window/system events and not doing any of the "Program", and secondly you have to ensure that all subprocces you have Self-empt (just made that up), after whatever is your time slice for it.

[deleted]

A Linear multi-task executor? PARADOX :)

It's not really able to pre-empt because you have to choose a time to go and look for events, to trigger the hook. Ideally when the timer ticks it would be a real hook, ie hooked into the o/s, so that the o/s itself calls the hook function immediately, pre-empting whatever else your app is doing. But it can't do that, from what I can tell. All it can do is wait for you to give control to the o/s so that it can transfer events to your app, so that Blitz can trigger the hook, which means having to wait and detect the presence of a timer tick. I don't see that there is really any way in Blitz to truly pre-empt. We don't have interrupts. We don't have the ability to make something happen when a timer ticks all by itself. We don't have a timer that can count down from a number and then trigger something by itself. We don't have threads. Processes can't really talk to each other. Hooks aren't really hooked into the o/s system functionality. The app is kind of isolated in its own world. So this is about as good as it gets - cooperatively multiasking with the o/s in order to get the events so that you can call your own hook. And like Skid said you can't really pre-empt because a function needs to end and return before the next one starts.

I've come up with a similar solution using a timer to trigger a scheduling event which pre-empts a current *script*, as part of a script interpretation engine, but then this is only possible by a) occasionally polling for events to trigger the timer tick event, and b) abstracting program execution away from real direct programs and into a script layer - once removed. It acts as though it is pre-emptive but in the script interpreter there is still that requirement to poll the system manually to cause a pre-emption, which in part is cooperative, not pre-emptive. Having some kind of interrupt-driven function would be great.