Class

Xojo.Threading.CriticalSection


Warning

This item was deprecated in version 2020r2. Please use CriticalSection as a replacement.

Description

Used to protect a single resource in a multithreaded environment.

Methods

Name

Parameters

Returns

Shared

Enter

Leave

TryEnter

Boolean

Method descriptions


Xojo.Threading.CriticalSection.Enter

Enter

Attempts to get a lock on the resource managed by the CriticalSection.

When the call to Enter succeeds, it returns and your code has exclusive access to the protected resource. If the lock cannot be obtained immediately, Enter will block the current thread from continuing to run. It will wait for the resource to become available.

Enter differs from the Signal method of the Semaphore class in that it can be called multiple times from the currently executing thread. If the calling thread already owns the lock, the method returns immediately. This makes CriticalSections very useful for calling a method recursively.


Xojo.Threading.CriticalSection.Leave

Leave

Call Leave when you are finished using the protected resource and you want to give it back to the CriticalSection.

Every time you call Enter or TryEnter and succeed, you must call Leave. This includes calling it recursively. Otherwise the resource will be protected indefinitely.


Xojo.Threading.CriticalSection.TryEnter

TryEnter As Boolean

Attempts to get a lock on the resource managed by the CriticalSection without blocking the app.

TryEnter is similar to Enter but returns a Boolean. If it succeeds, it returns True and the thread has exclusive use of the resource. If it fails, it returns False but does not block execution of the thread.

Notes

A CriticalSection is similar to a Semaphore, except a CriticalSection protects only one resource. The Semaphore class, on the other hand, can protect more than one resource.

You use critical sections in conjunction with Threads. In a situation in which two or more of the threads might try to access the same item, then you should enclose the code with calls to the Enter (or TryEnter) and Leave methods.

One strategy is this: * Create a subclass of Thread which does the operations that might compete for access to a resource. * Create a CriticalSection property of Public scope in, for example, the View that contains the control that calls the threads. * In the Run event handler of the Thread, call Enter and Leave before and after the code that tries to access the shared resource.

If a thread that has a lock crashes, the lock is not released.

Sample code

For example, if you have a logging file that multiple threads are writing to you may want to ensure that only a single thread has the file open for writing at one time. You could do this by having a WriteLog method that opens the file if it can get the lock. A property called LogFileAvailable As CriticalSection is initialized by the thread:

LogFileAvailable = New CriticalSection

And then a method can check it before it attempts to open the log file for writing:

Sub LogInfo(logText As Text)
  If LogFileAvailable.TryEnter Then
    Var file As FolderItem = SpecialFolder.Documents.("log.txt")
    file = TextOutputStream.Open(file, Encodings.UTF8)
    file.WriteLine(logText)
    file.Close
    LogFileAvailable.Leave
  End If
End Sub

Compatibility

All project types on all supported operating systems.

See also

Object parent class; Semaphore, Thread classes