In another thread, we were discussing that using Strings in preemptive threads should be safe. I found a way to crash it.
In this, there is a loop on the main thread, and a preemptive thread. Both of them assign a different string to a string (which is a Window Property) and then check to see if the string is what they assigned.
Since this is using a Preemptive thread, we would expect that sometimes the string would be different than what was assigned (since the other thread may have overwritten it).
Working on it. I would appreciate if anyone else can reproduce (perhaps using Xojo for Windows? I only use macOS).
Here’s a variation: instead of using a Window.Property, the string is now a Global module property. In this version, debug runs in the IDE don’t crash, but a built app does crash the same way:
Well for me example 1 crashes on a Macbook Air with M2 and macOS 15.0 when launched from IDE…built can’t test as I don’t have a license installed on it…
If i protect access to foobar with a critical section, i see no crashes on M1 Mac Mini. Without i see them, too.
But i think it’s no good idea to max out the main thread with processing, then the GUI blocks, as always. This should all be in other preemptive threads, no?
I suppose the question is just how preemptive the new thread type is. If assigning a string to a string property can be interrupted in at any stage (i.e., between machine instructions), then yes, writing to a shared property without first acquring that property via a semaphore, accessing the property, and then releasing the sempaphore, is very likely to lead to crashes.
No known language does it. Lots of overheads. It will increase the size of the app, slows it down doing unnecessary steps, and maybe even cause crashes due to having unknown layers of internal “semaphores” out of the control of the designer.
We need Xojo to clarify this, but here’s what they wrote:
[1]
Xojo has done a good job of making a lot of the framework safe, but that just means your app shouldn’t crash if, say, the Thread tries to manipulate a variable at the same time as other code. It’s up to you to make sure one area of your app doesn’t clobber the changes made by another.
and
[2]
What things are thread-safe?
We’ve updated our framework to safeguard areas that were previously not preemptive thread-safe. For the most part, our entire framework is now safe for concurrent use with preemptive threads, with a few exceptions like XojoScript and Runtime.IterateObjects. When sharing resources such as MemoryBlocks, Dictionaries, or Arrays among threads, you may need to use CriticalSections or Semaphores to ensure safe access. However, if you’re only reading from these resources without modifying them, synchronization is not required. You’ll be happy to know that calling Thread.AddUserInterfaceUpdate from a preemptive thread is also safe.
