I can't find the error in this program
option explicit
DECLARE SUB integral(byval start as integer, byval finish as integer)
DIM SHARED thread(1)
thread(0) = threadcreate( @integral, 0, 159 )
thread(1) = threadcreate( @integral, 0, 159 )
threadwait(thread(0))
threadwait(thread(1))
SUB integral(byval start as integer, byval finish as integer)
'does reaman sum
END SUB
Error 7, expected ")" found "," on the first threadcreate line
This is the compiler error I got:
Code:
test.bas(4) : error 1: Argument count mismatch, found: '159'
thread(0) = threadcreate( @integral, 0, 159 )
^
Make sure you check the definition of threadcreate, basically this error means you have an extra arguement (you have three, you should only have two ).
From the examples it seems it allows only for asingle argument to be passed to the functiom. Perhaps if you have more arguments you must pass a pointer to an UDT holding them. That's it, v1ctor?
If I recall, threadcreate requires two arguements, the address of the threaded procedure and that state flags which is either start running or start suspended.
Go figure, this is in no FM....
The full prototype is declared in the big DATA chunk at the beginning of src/compiler/rtl.bas...
Anyway, THREADCREATE accepts two arguments:
1) pointer to function to be executed as new thread. The function must be of the form
Code:
sub threadfunc( byval param as integer )
2) integer parameter to be passed to thread function. This is optional; if you don't specify it, threadfunc will receive 0 as param.
While I got the program to multitask I found that the program actually got SLOWER running four threads at once. The code uses a lot of memory swapping, and writes to the monitor. (Memory calls take about 4 processor ticks and video writes take about 10) During that empty period where it is waiting for a return, if there is another thread running it will do the next command in that one. Then why didn't it speed up, in every other language I've used the speed went through the roof.
All the other computer that I have multitasked on were much newer though, is it possibly a fault of the primative Pentium III?
Were the other machines you did it on the same architecture?
Are you accessing locked data in the threads, this will cause a gpf in the thread which accesses the data after it's been locked.
Are you structuring your data to be easly cachable?
Are you properly using mutexes and semaphores?
No, they were Suns and Macs, both 64bit hyperthreaded, in Java. Is that why it hasn't sped up?
If I recall, Windows automatically places a lock on data accessed in a threaded program and the lock isn't released until the thread ends. This would cause any shared data to be inaccessable in other threads. If the program is appartment modeled, then a copy of the shared dataspace is created for each thread and the results are merged when the threads end, this means the threads can run without problems, but the the results are unpredictable (which is why you're not supposed to do memory management in a thread).