Parallel Processing / Multi-Threading questions

[TWELVE]

Hello,

the application i'm currently building is doing a couple of things in parallel.Due to the lack of threading capabilities in Basic4PPC i found the timers to be a good replacement for the threads i'm using in the windows version of my application.

During testing of my app it turned out, that the GUI code and the code running in 2 different timers does not real run in parallel.In fact, if the code within a timer needs to wait for something ( e.g. wait until an internet connection has been established) , the entire application is waiting.

This makes me believe, that the whole executable is running in just one thread.When i read the docs, i did not find explicit references confirming this is true.

I searched the forum and found a 3rd party threading library, which indicates indirectly, that Basic4PPC does not have the capability of parallel processing.

My questions regarding this:

- is it true: all codes runs in just one thread( even the timers)..?

- is there any mechanism i could use to circumvent that, like OS Callbacks etc..?

- is the 3rd party Threading lib the only way out of this..?


I'm wondering why this matter is asked so rarely...have only a few people the need for doing things in parallel in their applications..?


cheers

TWELVE

[badkarma]

Not sure about threading but would the "DoEvents" command help out?

[agraham]

Originally Posted by TWELVE

- is it true: all codes runs in just one thread( even the timers)..?

Yes, everything runs off the main form's thread. The timers are windows messages processed (like everything else) by the main form's Window Procedure.

- is there any mechanism i could use to circumvent that, like OS Callbacks etc..?

Only from within a custom written library.

- is the 3rd party Threading lib the only way out of this..?

Yes. Presumably you have found my Threading library. Threading library for optimising compiler You may already be aware that the Windows GUI is not thread safe on either device or desktop so you must not manipulate anything to do with the GUI other than on the main thread. My library provides an events mechanism to assist this.

[RandomCoder]

Originally Posted by TWELVE

..... During testing of my app it turned out, that the GUI code and the code running in 2 different timers does not real run in parallel.In fact, if the code within a timer needs to wait for something ( e.g. wait until an internet connection has been established) , the entire application is waiting.

B4PPC is event driven, instead of having your program hang whilst waiting for the internet connection you could use the timer in a slightly different way.
I was thinking along the lines of initialise the connection and the timer. Then use the tick event to periodically check if the connection has established. Count the ticks and timeout if a preset limit is exceeded. This way your program can still perform other tasks in between ticks.

Regards,
RandomCoder

[TWELVE]

Then use the tick event to periodically check if the connection has established. Count the ticks and timeout if a preset limit is exceeded. This way your program can still perform other tasks in between ticks.

I do not just wait for the internet connection, i also want to use it then for a SMTP connection, for example.During mail transfer ( e.g. fileupload) the GUI gets frozen and i cannot interrupt the mail connection.So timers don't help here.Some task need to really run in parallel and can't give up their timeslice to serve other tasks in the App.Furthermore code-driven switching between tasks is comparatively complex and sensitive to code changes.

regards

TWELVE

[agraham]

Originally Posted by TWELVE

Some task need to really run in parallel and can't give up their timeslice to serve other tasks in the App.Furthermore code-driven switching between tasks is comparatively complex and sensitive to code changes.

I totally agree. That is why I wrote the Thread library as in some circumstances it makes very easy what would otherwise be very difficult.

You have probably noticed that, for simplicity and bug avoidence, Basic4PPC tends to only implement synchronous operations. Moving such operations onto a thread will effectively make them asynchronous as far as the main thread goes without having to resort to implementing asynchronous operations in custom written libraries for a particular application.

However running B4PPC code on separate threads is only supported by optimised compiled applications as the IDE and legacy apps are bytecode interpreted at runtime and so would need significant modification to the interpreter to support multiple threads of execution.

[TWELVE]

Thanks agraham for your contribution to this topic ( and for your lib too..;-) ).I will start to test your threading library soon and hope, this can be a solution for me.

Do you know, how VS is handling this..? As from the documentation, VS is able to handle threads.Also for code it produces for the mobile devices...?

kind regards

TWELVE

[agraham]

Originally Posted by TWELVE

Do you know, how VS is handling this..? As from the documentation, VS is able to handle threads.Also for code it produces for the mobile devices...?

I am afraid that I don't understand this question. However all my libraries are written in C# using VS2005. They are usually compiled for the Compact Framework on the device but most will also run on the desktop due to .NETs' ability to retarget Compact Framework code to the full .NET Framework. Most libraries are compiled for .NET 1.0/1.1 but a few require .NET 2.0 as they use functionality not present in version 1.0/1.1.

The threading library checks if it is running a compiled application and if so uses Reflection to pick up Basic4PPCs' internal table of Sub delegates (which Basic4PPC implements for use with "CallSub"). When Thread.Start(sub) is invoked it picks up the delegate for the Sub to be run on a separate thread, creates a new thread and runs the delegate on that thread.

The delegates for the RunLocked methods are picked up the same way but are run on the calling thread.