But when you do need that extra boost, it’s an option to consider, and I recently came across a scenario where it made a huge difference.

The (One Billion Row) Challenge

This came about from a discussion of the “One Billion Row Challenge” on the Xojo Forum, where a programmer is tasked with reading a billion rows of temperature data and consolidating it into statistics for each given city. Our friend Mike D started a project to demonstrate different techniques, and I eventually started my own project. Using MemoryBlock, Ptr, and preemptive threading, I was able to process a billion rows in roughly 8 seconds.

But that’s not the point of this post.

See, in order to process the data, you must first create it, which isn’t as straightforward as it seems.

Creating The Data

Each row of the data file takes the form “City;temp”, where “temp” is single-place decimal between -99.9 and 99.9. For purpose of limits, I used, arbitrarily, 413 random cities out of a list of all cities. The original code looked something like this where “bs” represents a BinaryStream:

Var r As New Random

For i As Integer = 1 To rowCount
  Var city As String = cities(r.InRange(0, cities.LastIndex))
  Var temp As Double = r.InRange(-999, 999) / 10.0

  bs.Write city + ";" + temp.ToString("#0.0") + EndOfLine
Next

This was simple, easy, and slow. To generate the full billion rows took about 2.5 hours.

Memory-Unblocking

Upon investigation, I rediscovered what I already knew. Dealing with strings, both in conversion and concatenation, can be a bottleneck. I won’t go through all the iterations here, but nothing I tried made a significant difference. The only solution was to ditch strings entirely.

I started with creating a MemoryBlock “buffer” (“outMB”) of 1 MB with an associated Ptr (“outPtr”). (You can access the contents of a MemoryBlock through its methods, but those are function calls, which have an overhead. Ptr methods are operators that work with the bytes directly so they are faster.) The plan was to fill the buffer as much as I could, write it to the file, then start again at the top of the buffer.

Keeping a position index, I started with writing the city using outMB.StringValue since there is no equivalent Ptr method for this. Next, I plugged in the value of a semicolon with outPtr.Byte(outMBIndex) = 59.

Working with integers is faster than doubles, so I used a little math to plug in the temperature values directly using If statements and outPtr.Byte.

Finally, I used outPtr.Byte(outMBIndex) = 10 to plug in the linefeed (ASCII 10).

The final code looked something like this:

Const kEOL As Integer = 10
Const kHyphen As Integer = 45
Const kDot As Integer = 46
Const kZero As Integer = 48
Const kSemicolon As Integer = 59

Var r As New Random

Var outMB As New MemoryBlock(1000000)
Var outPtr As Ptr = outMB

Var outMBIndex As Integer = 0

For row As Integer = 1 To rows
  Var cityIndex As Integer = r.InRange(0, cities.LastIndex)
  Var city As string = cities(cityIndex)
  Var cityBytes As Integer = city.Bytes

  If (outMBIndex + cityBytes + 10) >= outMB.Size Then
    bs.Write outMB.StringValue(0, outMBIndex)
    outMBIndex = 0
  End If

  outMB.StringValue(outMBIndex, cityBytes) = city
  outMBIndex = outMBIndex + cityBytes

  outPtr.Byte(outMBIndex) = kSemicolon
  outMBIndex = outMBIndex + 1

  If r.InRange(0, 4) = 0 Then
    outPtr.Byte(outMBIndex) = kHyphen
    outMBIndex = outMBIndex + 1
  End If

  Var temp As Integer = r.InRange(0, 999)
  Var t1 As Integer = temp \ 100
  Var t2 As Integer = (temp \ 10) Mod 10
  Var t3 As Integer = temp Mod 10

  If t1 <> 0 Then
    outPtr.Byte(outMBIndex) = t1 + kZero
    outMBIndex = outMBIndex + 1
  End If

  outPtr.Byte(outMBIndex) = t2 + kZero
  outMBIndex = outMBIndex + 1

  outPtr.Byte(outMBIndex) = kDot
  outMBIndex = outMBIndex + 1

  outPtr.Byte(outMBIndex) = t3 + kZero
  outMBIndex = outMBIndex + 1

  outPtr.Byte(outMBIndex) = kEOL
  outMBIndex = outMBIndex + 1
next

If outMBIndex <> 0 Then
  bs.Write outMB.StringValue(0, outMBIndex)
End If

This code is far longer, harder to follow, and difficult to maintain, which goes back to my original point of why MemoryBlock should be avoided.

It also generates one billion rows of data in about a minute (as opposed to 2.5 hours).

It’s nice to have the option.

Kem Tekinay is a Mac consultant and programmer who has been using Xojo since its first release to create custom solutions for clients. He is the author of the popular utilities TFTP Client and RegExRX (both written with Xojo) and lives in Connecticut with his wife Lisa, and their cat.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Protecting Our Objects

Xojo objects are uniquely constructed and reference counted, a detail most users don’t need to think about. However, when working with preemptive threads, objects inherently require special protection. In Xojo 2024r3.1, we implemented safeguards to enable the use of objects in preemptive threads, but the approach wasn’t as efficient as it could be. Operations like passing objects as parameters or assigning them as properties incurred overhead, and those costs added up.

As uniquely as our objects are to construct, they also required a unique approach to protect them. In Xojo 2024r4 we updated how we protect our objects so that this operation happens much faster, improving the overall experience when running preemptive threads.

For an example of these efficiencies, check out this forum post where users benchmark the One Billion Row Challenge.

Uniquely Destructed Objects

As mentioned, our objects are uniquely constructed, and this uniqueness extends to their destruction as well. When a preemptive thread is running, it’s important not to wait for other objects to be destructed within the Destructor method.

Sub Object1.Destructor()
  While Object2 <> Nil
    // Waiting for Object2 to be destructed can lead to a deadlock,
    // especially if Object2 is being destructed from a separate thread.
  Wend
End Sub

Also, avoid situations where you are creating new objects while in the Destructor and referencing Self.

Sub Object1.Destructor()
  // Referencing Self in a new object will lead to a
  // recursive Destructor sequence causing a dead lock.
  Var newObj As New Class1
  newObj.NotAGoodIdea = Self
End Sub

Handling Race Conditions

In Xojo 2024r3.1, we created an example demonstrating how to synchronize shared resources using critical sections and semaphores. This example also highlights the effect of a race condition: your app will crash immediately, terminating the debugging session with no indication as to where the crash may have occurred.

These access violations were never caught by our debugger until now. Because these crashes may interfere with what can be displayed in the debugger, we’ve intentionally limited what is shown, as the access violation could leave the app in an unstable state. Although these access violations are not exclusive to crashes caused by race conditions, this new feature aims to help you identify potential race conditions in your apps when working with preemptive threads. Let’s take a look at that example and see what happens now when you run it through the debugger:

When you click the button designed to intentionally crash the app, you’ll now be returned to the debugger, where you’ll see a new crash icon. This symbol indicates that a crash has occurred, and the app cannot proceed further (which is why all debugging step commands are disabled, and the debugger values are not loaded so objects will be Nil). Your only options at this point are to stop the app or attempt to reload the debugger values.

Clicking the command button on the left refreshes or reloads the debugger values. If the app is stable enough, the debugger values will refresh; otherwise, the app may terminate automatically at this point.

In summary, these improvements aim to make working with preemptive threads more enjoyable by offering both enhanced speed and an easier process for identifying potential race conditions, which was previously much more challenging. Like the One Billion Row Challenge, we’re eager to hear about all the ways you’re making use of preemptive threads in your own apps!

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

What’s New in Xojo 2024r4

Xojo 2024r4 brings a range of exciting updates that enhance cross-platform development, improve security, and provide more tools for creating dynamic and interactive applications. Here are some of the standout features:

Web Framework
Enjoy smoother and more efficient web applications with updates to Xojo’s Web Framework. Improved memory usage and numerous bug fixes ensure that your web apps run reliably and perform optimally, providing a better experience for your users.

Discover Web Framework Improvements

These updates and enhancements are designed to make your development process more efficient, productive, and enjoyable. Whether you’re building new applications or enhancing existing ones, Xojo 2024r4 provides the tools and capabilities you need to succeed.

Get Started

To learn more about Xojo 2024 Release 4 and begin your development journey, please visit the Xojo 2024r4 Release Notes. The update is available for download now from the Xojo downloads page.

What’s Next?

We’re continuously working on new features, updates, and enhancements to our platform. If you have any suggestions or ideas, please add them to the Xojo tracker. We’re always looking to improve and expand Xojo to better serve our community.

Thank you for being part of the Xojo community. We’re excited to see what you create with Xojo 2024r4!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

In The Beginning

Threads have been a part of of the Xojo language for a long time, and by now experienced users know the basics: subclass a Thread, fill in the Run event, then call Start. The code in Run will execute independently from the rest of your code leaving your app responsive while it does work in the background.

Mostly.

See, until now, a Thread was only “cooperative”, meaning it ran alongside your main code with the framework deciding when to switch between them and how long each should execute. While the main code was running, the Thread code was paused, and while the Thread was running, the main code was paused.

Think of it like standing before two devices that perform different functions when cranked, but only having one crank available. You run the first machine for a bit, then the other, then back to the first, until they are done. And you do it really, really fast.

This worked pretty well when your goal was, say, to keep your user interface responsive. You could spin long-running code into a Thread, then present the results once it finished.

But it was inadequate if your objective was to speed up some intense process, or the code in your Thread did not present logical places to yield time back to your main code. In the former scenario, you were better off not using a Thread, or perhaps using Worker (a severely limited earlier attempt at allowing simultaneous processing), while in the latter you would have to manually yield back processing time, leading to even slower operation.

In The Now

Cooperative threads are fine for many tasks, but when you need something that truly runs independently within your app, a “preemptive” thread is required.

A preemptive thread spins off onto another core in your machine, which probably has at least four, and runs there entirely isolated from other threads. It’s like launching a separate, mini-app that you can share information with.

The limitations that apply to cooperative threads drop away. Since it runs on a different core, it cannot slow down or interfere with your main code, and will run as fast as its core will allow.

Challenging Times

This sounds almost too good to be true, but it’s not without its challenges. While cooperative threads were rather easy to work with, preemptive threads require an extra layer of thought and awareness for Xojo users.

When a cooperative thread’s code is running, you know nothing else is, so you don’t have to worry about, say, updating a Dictionary or removing an element from an array. But with preemptive threads, code runs simultaneously with other code so you cannot just update that Dictionary if there is a chance that the main code, or another preemptive thread, might be doing it too.

Consider this example.

// In our thread
If MyArray.Count = 0 And FinishUp Then
  Exit
Else
  Process MyArray.Pop
End If

//////////////////////////////

// In the main code
FinishUp = True
MyArray.Add 1

You might think the thread is going to process the last element and then exit its loop because FinishUp was set to True, but with preemptive threads we have to be aware of race conditions where the order of actions is unpredictable. Here, the main code could set FinishUp to True, and the thread could see that MyArray was empty and exit before the main code could add the last element. Conditions can change at literally any instant, even in the middle of a single line of code.

Fortunately, there are ways to protect against this and you must use them to ensure orderly operation and avoid surprises.

Know Your Type

The first step is creating a preemptive thread, and Xojo’s implementation is pretty straightforward. Rather than introducing a unique class, you can continue to work with the existing Thread by setting its new Type property to Thread.Types.Preemptive. The Type can be set when instantiating the Thread or from within its running code. You can even switch types at will, although once running, the Type can only be changed from within the Thread.

Example:

// A subclass of Thread called PThread

MyThread = New PThread
PThread.Type = Thread.Types.Preemptive
PThread.Start

Or within the Run event, you could do this:

Me.Type = Thread.Types.Preemptive

You can also set Type through the Inspector after dragging a Thread to a window.

Protect Yourself

Now that you have a preemptive thread ready to go, you have to think about how to protect common resources. 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.

Consider this code that maintains a Dictionary of Integer arrays.

// Thread code
Var arr() As Integer

If MyDictionary.HasKey(x) Then
  arr = MyDictionary.Value(x)
Else
  MyDictionary.Value(x) = arr
End If

arr.Add 1

//////////////////////////////

// Main code
If Not MyDictionary.HasKey(x) Then
  Var arr() As Integer
  MyDictionary.Value(x) = arr
End If

Run this long enough and you’re going to wonder why some data got lost. Why? Because both the Thread and main code might be checking for the key at the exact same instant and filling it in when it’s not found. If the Thread does it first, the main code will almost instantly replace it with an empty array.

Instead, you should use a Semaphore or CriticalSection to make sure code is protected.

You’d first instantiate one of these in a common property like a Window or Module. (I’m using Semaphore here, but it works the same for CriticalSection.)

MySemaphore = New Semaphore
MySemaphore.Type = Thread.Types.Preemptive

Notice the new Type property? It must match the one in Thread and can be used between the main code and a Thread or between same-typed threads. (This is one of the limitations of Xojo’s implementation: you cannot share a Semaphore or CriticalSection between preemptive and cooperative threads.)

The example can be updated like this:

// Thread code
Var arr() As Integer

MySemaphore.Signal

If MyDictionary.HasKey(x) Then
  arr = MyDictionary.Value(x)
Else
  MyDictionary.Value(x) = arr
End If

MySemaphore.Release

arr.Add 1

//////////////////////////////

// Main code
MySemaphore.Signal

If Not MyDictionary.HasKey(x) Then
  Var arr() As Integer
  MyDictionary.Value(x) = arr
End If

MySemaphore.Release

This will force either the main code or Thread to wait for the other to complete before continuing, ensuring proper order and avoiding the race condition.

Limitations

Using preemptive threads comes with certain restrictions. The biggest one is the aforementioned inability to share a Semaphore or CriticalSection with a cooperative thread. The other is the same as in a cooperative thread: you cannot update a user interface component directly instead relying on the UserInterfaceUpdate mechanism (more on that below).

If you are setting up multiple threads to work on different parts of some object, that may crash hard depending on the type of object. For example, writing to the same file or different parts of a MemoryBlock is fine, but updating a Picture may not be. In those cases, you will have to get creative.

What’s It Good For?

Choosing preemptive threads over cooperative means that you either have some code that needs to truly run in the background that would otherwise interfere with you user interface, or you have some large task that can be logically processed in parts.

Window Service

In the former case, the easiest technique might be to drag a Thread to your window, set its Type, and implement the Run event. It can be started from within the window either through a manual process like a pressing a button, or automatically when the window opens.

Just like with a cooperative thread, you can send data back to your window using the AddUserInterfaceUpdate method and implementing the UserInterfaceUpdate event.

Splitting It Up

If your task involves something that can be split up into logical chunks, I encourage you to look at my ThreadPool module, accessible through the Xojo Examples or my GitHub page. (The latter has a README with more details.)

The ideal usage for ThreadPool is when you have some data that can be processed in sections. For example, suppose you wanted to count the vowels in a large file. You could subclass ThreadPool and implement its Process event to count one block. You would then send the file into your subclass in chunks of, say, 256k each and gather the results.

The benefit of ThreadPool, among other things, is that it will handle the coordination for you so the dangers of using preemptive threads are minimized. You still have to consider how to send your results back to your main code safely, perhaps using Semaphore/CriticalSection or the AddUserInterfaceUpdate method, but each block can be considered independently of the others.

(A big thanks to MVP Anthony Cyphers for writing the example included with Xojo.)

Juggling Chainsaws

The power of preemptive threads is clear, but the potential pitfalls can be serious. Unless you’re very careful, you can easily create bugs that may not be readily apparent, and may take hours or even days to track down. (I say this from unfortunate experience.) Unless you have a compelling reason to take on that challenge, don’t bother.

What I’m trying to say is, if a cooperate thread does the job adequately, there is no need to introduce the headache that preemptive threads can bring.

But if you do have a legitimate need, like a long-running process that needs to run quickly without blocking your UI, go for it, just be careful.

In any case, it’s great that we finally have that option.

Kem Tekinay is a Mac consultant and programmer who has been using Xojo since its first release to create custom solutions for clients. He is the author of the popular utilities TFTP Client and RegExRX (both written with Xojo) and lives in Connecticut with his wife Lisa, and their cat.

Need More Information? Read more about preemptive threads in the Xojo Documentation and Blog. Or read about Semaphore and CriticalSection, also on the Xojo Blog.

Threading Models

Cooperative Threads: This is the threading model that Xojo has traditionally supported and continues to offer. In this model, threads must voluntarily yield control at specific points that we define. This ensures that most operations in Xojo code are thread-safe, as we manage access to MemoryBlocks, Arrays, etc. However, this approach can lead to inefficiencies if a thread fails to yield, potentially blocking UI, and because only one thread runs at a time, it doesn’t fully utilize multiple cores or truly run in parallel.

Preemptive Threads: Introduced in Xojo 2024r3, this new thread type allows threads to be interrupted at any point, enhancing responsiveness and fully utilizing multiple cores. While this model provides significant performance improvements, it also introduces new challenges. Because threads can be interrupted at any time, you’ll need to be more diligent about locking resources, such as MemoryBlocks and Arrays, to avoid potential race conditions.

Using Preemptive Threads

We’ve added a new Thread.Type property that allows you to switch your threads to the new preemptive thread model, here’s how you can start one up:

Thread1.Type = Threads.Types.Preemptive
Thread1.Start

You can set this property either before starting your thread or while the thread is running. However, if changing it while the thread is active, it must be done safely from within the running thread itself, and not externally.

Event Window1.Opening
  // Start the thread and setup the type in the Run event instead
  Thread1.Start
End Event

Sub Thread1.Run
  Me.Type = Threads.Types.Preemptive
  // Run a very long process preemptively.
  newMemBlock = memBlock.Compress
  
  Me.Type = Threads.Types.Cooperative
  // Switching to cooperative mode and modifying a shared array safely.
  mySharedArray.Add("New item")
End Sub

Concurrency and Synchronization

As mentioned earlier, cooperative threads avoid many of the issues that arise with preemptive threads, since we control when thread switching occurs. With preemptive threads, however, you can no longer safely modify things, like shared arrays, the same way you could before with cooperative threads. To manage this, you’ll need to use tools like CriticalSections and Semaphores more frequently to protect your shared resources.

The challenge lies in efficiently supporting both threading models while enabling the main thread to synchronize with either type. To address this, we’ve added a new Type property to CriticalSection and Semaphores, which must match the thread type you’re using to protect shared resources.

// Imagine the main thread and two additional threads all trying to access a Dictionary simultaneously.
Sub RunTest
  Thread1.Type = Thread.Types.Preemptive
  Thread2.Type = Thread.Types.Preemptive

  CSLock = New CriticalSection
  // Since we are using this CriticalSection in preemptive threads,
  // the synchronization type must be compatible.
  CSLock.Type = Thread1.Type

  Thread1.Start
  Thread2.Start

  Do
    CSLock.Enter
    MyDictionary.RemoveAll
    CSLock.Leave
  Loop
End Sub

Sub Thread1.Run
  Do
    CSLock.Enter
    MyDictionary.Value("Random1") = Rnd
    CSLock.Leave
  Loop
End Sub

Sub Thread2.Run
  Do
    CSLock.Enter
    MyDictionary.Value("Random2") = Rnd
    CSLock.Leave
  Loop
End Sub

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.

Performance Considerations

With the ability to switch your threads to preemptive, there are some performance factors to consider. While running 100 threads at once might seem appealing, it often leads to over-utilizing your system’s resources. For optimal efficiency, it’s best to limit the number of threads to match the number of available cores. To assist with this, we’ve introduced the new System.CoreCount, which helps you determine the number of cores on your system.

While Xojo’s framework doesn’t shield you from every potential issue, we do handle synchronization for key operations like object creation and destruction. However, you may notice these actions are slower in preemptive threads due to the extra synchronization required.

Usage and Examples

There’s no question that preemptive threads offer significant advantages, and when used correctly, they can greatly enhance your app’s performance. Check out our threading example projects included with the 2024r3 release to see preemptive threads in action and enjoy weaving these new threads into your future apps!

A special thanks to our MVPs for their invaluable help in refining and testing this new feature! Be sure to check out the new ThreadPool example for some practical, real-world use cases and read MVP Kem Tekinay’s blog post Preemptive Threads Are Here and They Are …. Pretty Good.

Need More Information? Read more about preemptive threads in the Xojo Documentation and Blog. Or read about Semaphore and CriticalSection.

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

What’s New in Xojo 2024 Release 3

We’ve been working hard to bring you the best possible cross-platform development experience, and Xojo 2024 Release 3 delivers. Here are some of the highlights:

These updates and enhancements are designed to make your development experience more efficient, productive, and enjoyable. Whether you’re building a new application or updating an existing one, Xojo 2024 Release 3 provides you with the tools and capabilities you need to succeed.

Get Started

To learn more about Xojo 2024 Release 3 and to get started with the development process, please visit the Xojo 2024r3 Release Notes. The update can be downloaded right now, from the Xojo downloads page.

What’s Next?

We’re always working on new features, updates, and enhancements to our platform. If you have any suggestions or ideas, please don’t hesitate to add them to the Xojo tracker. We’re always looking for ways to improve and expand Xojo.

Thank you for being part of the Xojo community. We’re excited to see what you’ll create with Xojo 2024r3!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube