But timers have a limit: they still run on the UI thread. If your background work is genuinely heavy (database queries, file I/O, complex calculations), a timer won’t save you. You need actual background processing and that’s where threads come in.

The Core Idea: Threads

A thread is a separate execution path that runs outside the UI thread. While your thread does the heavy lifting, the UI stays responsive to clicks, typing, scrolling. When your thread finishes a chunk of work, it notifies the UI thread via UserInterfaceUpdate, and only that callback runs on the main thread.

The rule is simple: threads cannot touch UI controls directly. If you try, you get a crash. UserInterfaceUpdate is your bridge.

For a deeper dive into how Xojo’s threading model works under the hood, including cooperative vs. preemptive threading, see Cooperative to Preemptive: Weaving New Threads Into Your Apps.

Let’s Code

Prerequisites: Add a StatusLabel (DesktopLabel), a DesktopButton, and a Thread control. Also define:

kCountTo As Integer = 100

The Thread Control

Drag a Thread from the library into your window and name it BackgroundWorker.

The Button (Start the Thread)

Place this in the Pressed event of a button:

Sub Pressed()
  If BackgroundWorker.ThreadState = Thread.ThreadStates.NotRunning Then
    BackgroundWorker.Start
  End If
End Sub

This checks if the thread is already running. If not, start it. This prevents multiple threads from piling up if someone clicks fast.

The Thread.Run Method (Background Work)

Implement the Run method on your Thread:

Sub Run()
  For i As Integer = 0 To kCountTo
    
    ' Do background work here. No UI access allowed.
    ' It can be: database query, file read, API call, pretty much anything that might block "freeze" the UI of the app
    
    ' Prepare a Dictionary payload for the UI
    Var info As New Dictionary
    info.Value("progress") = i
    info.Value("message") = "working"
    Me.AddUserInterfaceUpdate(info)
    
    ' Sleep (optional)
    Thread.SleepCurrent(10)   // Sleep 10 ms
  Next
End Sub

The key line is Me.AddUserInterfaceUpdate(info). This queues data for the UI thread to process. Each call adds one item to a queue, and the UI thread drains it in UserInterfaceUpdate.

The Thread.UserInterfaceUpdate Method (UI Sync)

Implement this event to handle updates from the thread:

Sub UserInterfaceUpdate(data() As Dictionary)
  ' Runs on the main UI thread. Safe to update controls here.
  
  ' Guard against empty or malformed data
  If data = Nil Or data.Count < 0 Then Return
  
  Var d As Dictionary = data(0)
  
  ' Extract the progress value safely
  Var progress As Integer = 0
  If d.HasKey("progress") Then
    progress = d.Value("progress").IntegerValue
  End If
  
  ' Update the UI
  StatusLabel.Text = progress.ToString
  
  ' Mark completion when we hit the target
  If progress >= kCountTo Then
    StatusLabel.Text = "done"
  End If
End Sub

Important notes:

• data() is an array of Dictionaries.
• Always check HasKey before accessing a value to avoid runtime errors.
• Use .IntegerValue (or .StringValue, etc.) to safely extract values.
• This runs on the UI thread, so it is safe to update StatusLabel and any other visual controls.

How It Works

1. Button press: Click the button and the thread starts.
2. Background loop: The thread iterates from 0 to kCountTo, sleeping 10 ms each step. After each step, it queues an update.
3. Responsiveness: While the thread works, you can still interact with the rest of your application. No freezing.

A Note on Thread Safety

Threads are powerful but risky if misused. Here is the boundary:

• Safe in Run(): Anything that doesn’t touch UI controls. File I/O, database queries, calculations, network calls.
• Unsafe in Run(): Reading or writing UI control properties directly. StatusLabel.Text = ... is a no no!
• Safe in UserInterfaceUpdate(): All UI control access. This runs on the main thread.

If you forget this rule and try to update a label from inside Run(), your app will crash with a ThreadAccessingUIException. Instead pass data through AddUserInterfaceUpdate.

When to Use Threads vs. Timers

Use timers for:

• Short, frequent tasks (10-50 ms ticks).
• Simple progress updates.
• Cases where you are just deferring work a bit.

Use threads for:

• Long-running operations (seconds, minutes, hours).
• Genuinely blocking work (I/O, network, heavy calculations).
• Multiple independent background tasks.

In this series, we moved from blocking the UI to using timers on the UI thread, then to actual background threads. Each approach solves a different problem.

Wrapping Up

Threads are the heavy artillery of responsive design. They run independent of the UI and communicate safely via UserInterfaceUpdate. Once you grasp the boundary between thread code and UI code, you can build applications that never freeze, no matter how much work is happening behind the scenes.

See the Thread documentation for more details on priority, stack size, and advanced patterns.

Until then, happy threading!

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Optimizing Code Series:

• Optimizing Xojo Code, Part 1: Getting Started
• Optimizing Xojo Code, Part 2: Using a Timer to Keep the UI Responsive
• Optimizing Xojo Code, Part 3: Programmatic Timers and AddHandler
• Optimizing Xojo Code, Part 4: Timer.CallLater
• Optimizing Xojo Code, Part 5: Threads and UserInterfaceUpdate

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

In Xojo, CriticalSection is a primary tool for handling synchronization, and understanding how to use CriticalSection can help developers create responsive and stable applications.

Understanding CriticalSection

A CriticalSection controls access to a particular code section, ensuring that only one thread can execute that section at any given time. In Xojo, you can use a CriticalSection to prevent multiple threads from simultaneously accessing shared resources, which could lead to inconsistent data or program crashes.

Functioning as a lock, CriticalSection allows a thread to enter and secure the section, blocking others until it exits and releases the lock. This mechanism guarantees controlled and predictable access to shared resources.

CriticalSection in Xojo: Usage and Implementation

CriticalSection can be used in multi-threaded applications when certain operations require exclusive access to shared resources. Consider using CriticalSection in the following scenarios:

• Data Integrity: Protect shared data by ensuring atomic operations when accessed or modified by multiple threads. This maintains data integrity.
• Avoiding Race Conditions: Prevent race conditions by allowing only one thread to execute a critical code segment at a time.
• Resource Management: Manage resources such as file handles, network connections, or hardware interfaces by preventing conflicts and ensuring safe usage.

Implementation

Implementing a CriticalSection in Xojo is straightforward and involves a few key steps. Here’s how you can do it:

Public Property myCriticalSection As CriticalSection
Sub Opening() Handles Opening
  myCriticalSection = New CriticalSection
End Sub

Sub Run() Handles Run
  // Lock this section of code
  App.myCriticalSection.Enter
  
  Try
    // Perform critical operations
    
  Finally
    // Unlock this section of code once the job is done.
    App.myCriticalSection.Leave
  End Try
End Sub

Best Practice: Always use a Try…Finally block to ensure that the Leave method is called, even if an exception occurs. This prevents deadlocks by ensuring the lock is always released.

CriticalSection vs. Semaphores or Mutexes

While CriticalSection is powerful for managing access to shared resources, Xojo offers other synchronization mechanisms:

Conclusion

Choose the synchronization mechanism that perfectly aligns with your application’s unique needs to achieve peak performance and efficient resource management. While CriticalSection offers a straightforward solution for many scenarios, alternatives like Semaphores and Mutexes can provide additional flexibility in more complex situations.

Happy coding!

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

Read more about Semaphores: Using Semaphores to Manage Resources

In software development, where multiple threads often need to access shared resources like files or databases, semaphores bring order to potential chaos. They prevent data corruption and ensure applications run smoothly and efficiently, even during peak processing times.

Concurrent programming often requires multiple processes to access shared resources simultaneously. Without proper management, this can lead to conflicts and unpredictable behavior. Semaphores offer a solution to this challenge, acting as traffic lights to control access to these shared resources.

Why Use Semaphores?

Semaphores are crucial for:

• Preventing Race Conditions: In concurrent systems, a race condition occurs when the program’s outcome depends on the unpredictable timing of events. Semaphores help avoid this by ensuring that operations on shared resources happen in a controlled order.
• Ensuring Data Integrity: When multiple threads access shared data, there is a risk of data corruption if one thread modifies the data while another is reading it. Semaphores prevent this by allowing only one thread to modify the data at a time.
• Improving Efficiency: Semaphores can improve the performance of multi-threaded applications by reducing the time threads spend waiting for access to shared resources.

Sempahores in Xojo

Xojo provides the Semaphore class for managing concurrency. This class uses a counter to represent the number of resources available.

Here is how to use a Semaphore to protect access to a shared resource:

1. Acquire a Lock: Call the Signal method on the semaphore before accessing the resource. If a resource is available, the thread acquires the lock and continues. If not, the thread waits until a resource becomes available.
2. Perform the Operation: Access and manipulate the shared resource.
3. Release the Lock: Call the Release method on the semaphore after you finish with the resource. This action makes the resource available for other threads.

Example:

Let’s say you have multiple threads that need to write to the same file. Using a Semaphore, you can ensure that only one thread writes to the file at a time, preventing data corruption.

Initialization
Define a Semaphore in the application class to control file access to an important file

Public Property FileAccess As Semaphore 

Initialize the semaphore in the App.Opening event handler with a count of 1, meaning only one thread to access the file at a time

Sub Opening() Handles Opening
  FileAccess = New Semaphore(1)
End Sub

Access in Threads
Use the Semaphore in a thread to safely read from or write to the text file.

Sub Run() Handles Run
  // Acquire the semaphore to access the file
  App.FileAccess.Signal
  
  Try
    // Perform file operations
    WriteTextToFile(SpecialFolder.Desktop.Child("important_file.txt"), "This is a line of text.")
  Finally
    // Release the semaphore to allow other threads access
    App.FileAccess.Release
  End Try
End Sub

Public Sub WriteTextToFile(f As FolderItem, text As String)
  // Helper method
  
  Var outputStream As TextOutputStream
  
  Try
    If f.Exists = False Then
      outputStream = TextOutputStream.Create(f)
    End If
    outputStream = TextOutputStream.Open(f)
    outputStream.WriteLine(Text)
    
  Catch e As IOException
    // Handle file I/O errors
    MessageBox("Error writing to file: " + e.Message)
  Finally
    If outputStream <> Nil Then
      outputStream.Close
    End If
  End Try
End Sub

Benefits of Semaphores in Xojo

Using Semaphores in Xojo applications offers numerous advantages:

• Resource Fairness: Ensure fair access to shared resources among all threads.
• Resource Management: Control access to shared resources, preventing conflicts and ensuring data integrity.
• Performance Optimization: Reduce wait times and improve overall application speed by limiting concurrent access.
• Efficient CPU Utilization: Prevent unnecessary CPU usage by allowing threads to wait without consuming resources.
• Enhanced Responsiveness: Create a more responsive user interface by ensuring smooth execution of critical code.
• Improved Scalability: Maintain performance even as resource demands increase.
• Thread Synchronization: Coordinate the execution of multiple threads for predictable program behavior.
• Deadlock Prevention: Avoid situations where threads wait indefinitely for each other.

Conclusion

Semaphores are essential tools for managing concurrency in Xojo applications. They provide a simple yet powerful mechanism for controlling access to shared resources, preventing race conditions, and ensuring data integrity. By incorporating semaphores into your multithreaded Xojo applications, you can achieve better performance, reliability, and scalability.

Don’t forget to check the official Xojo documentation about Semaphore at https://documentation.xojo.com/api/language/semaphore.html

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube