Converting to preemtive threads

Before converting the functions in all classes (60) using preemptive threading I would like to be sure if the conversion method is correct.

Old features :

var result as boolean
MSMSemaphore.signal
Try
  ''' Code write shared variable
Catch
  
end Try
MSMSemaphore.release 
return result

New features :

var result as boolean
var SyncThread as new LockHolder( SemaphoreObj)

''' Code write shared variable
SyncThread = nil
return result

It looks like Semaphore is used as a synclock-like object in VB. Is that so?

Are there any other things to pay attention to?

Update:
I modified a class with the preemptive thread.
The program starts without error but the main window does not appear.
The IDE fails to finish debugging. I noticed that unlike the non-preemptive thread, a background process is created that.
I have to close with the task manager.
CPU usage is 0%

As preemptive threads are new, it would be great if Xojo provided several examples of “From this way, to that way.” They would cover both technique and some evaluation guidelines for deciding what processes would or wouldn’t benefit. Perhaps a few words about the additional time overhead would help; something like, “The savings has to be “this” much to benefit from “that” additional overhead.”

What’s this?

Your “old one” looks one of the correct approaches if well implemented.

To see how to implement preemptive treads i looked at Xojo examples.
My application (main form) interacts with objects that contain and manage threads and interlocks for sharing data with other threads or with local variables.

By modifying just one class as described above the application is no longer running as an application but as a background process.

My problem is not choosing which interlock to use (semaphore or critical section) but understanding why using threads in preemptive mode the application is running as a process.

Using not preemptive treads:

Using preemptive treads:

The short answer is that it doesn’t. It never makes it a separate process. Are you using Workers in your code? They do that. Equally, a single thread will only run at 100% of a single CPU core. If you want to use more than one core you would have to use something like a thread pool, which breaks up the task into multiple instances of your thread splitting the load across multiple CPU cores.

It’s also worth pointing out that Primitive threads do not run Primitive in the debugger (at least not at this time).

Maybe I didn’t explain myself well.
If I convert only a class in the entire project with the Preemptive Threads all the program runs as a process and therefore also the main window which is not displayed.
To close the program I have to use the Task Manager because the Xojo IDE is no longer able to do it.

I don’t use the worker in my project

Primitive ??

Preemptive

It is more likely that something in your not shown code is causing this.

Also build the app and test a “release”, not debug version and observe the behavior.

Can you please create a simple example project and add it to a Feedback Case? Thank you.

1 Like

Unless you’re talking about my ability yo spell, no. Preemptive :rofl: :joy:

Yo-yo!

Riding the grammar horse for a few more minutes:

Why are preemptive threads called preemptive threads? Following some grammar sources I learned it’s about being first to prevent a foreseen bad situation; if computer sciences are included they say it’s about being able to stop a thread and continue it later.
Which sounds rather like the cooperative model to me.

Does the name refer to early developments with single core CPUs that could not really run things in parallel? Or what definition did I miss?

In general I would say that cooperative threads yield the CPU when they feel like it, not because of some outside action. Ordinarily cooperative Xojo threads may yield at certain points anyway, such as in loops, but thats simply built in and can be prevented.

With a pre-emptive thread, it may be interrupted at any point in its execution and another thread resumed. Even between statements, in other words. So an object you may be working with in a pre-emptive thread might have its state changed when you don’t expect it. Which in turn is why when working with such objects, all pre-emptive threads that may use the object should be written to agree to use the same semaphore to serialise, and hence protect, such access.

A preemptive event, is a event that may occur BEFORE the opportunity of others promoting their own events, and as such it may interfere in the results of other events, changing them and even even canceling them. It will happen as soon as possible without anyone yielding them cooperatively one opportunity, the event may arise anywhere, anytime, that’s why it is called preemptive.

When in doubt
 ask ChatGPT (ツ)

Preemptive threads are called preemptive because the operating system can preempt, or interrupt, their execution at any time to switch to another thread. This contrasts with cooperative threading, where threads voluntarily yield control to allow others to run.

When not in doubt just write about it.

I created a small program to test threads in preemtive mode. The program consists of two objects. Both of which have a trhread that increments the value of a common variable. The program seems to work but is very slow.
It takes unfortunately about 6 seconds to increase from 0 to 2000. You can find the test file in the following link.

Note: The App take 0% of CPU

Threads Test preemptive.zip (5.8 KB)