Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

AVEVA Enterprise SCADA BLT API Reference

Work with thread-safety and Business Logic Tier (BLT) components

Work with thread-safety and Business Logic Tier (BLT) components

Since a Business Logic Tier (BLT) component can be executed simultaneously by multiple callers, it is extremely important that any shared resources or critical sections in the code are protected using some type of synchronization primitive.

Whenever you need to execute a section of code without interruption by another thread, you can use the lock statement. The lock statement protects the code within the lock’s scope (usually between two curly brackets) so that only one thread can enter at a time. The lock is automatically released when the locking thread leaves the lock’s scope, which allows the next thread to enter the locked section.

Another mechanism to ensure only one thread at a time uses a shared resource is a mutex. A mutex is a synchronization primitive that grants exclusive access to a shared resource. If a thread acquires a mutex, the second thread that attempts to acquire the mutex is suspended until the first thread releases the mutex or until an optional wait time-out is exceeded. If the second thread times out, it may retry acquiring the mutex or handle the failure in a different way.

Locks are recommended when the scope of the code to be protected is small and localized, for example, a block of code in a method. However, locks are limited to controlling access to the threads within a single application. Locks do not span multiple applications.

Mutexes are suitable when the scope for protection is larger, for example, across multiple method calls or between multiple applications. For example, multiple BLTHost processes that use a shared library to access a common resource could use a global mutex to ensure that only one thread out of all the BLTHost processes could access the shared library at a given time.

Example code 1

A critical section is used to publish data using the PubSub connection. This use ensures that no other thread publishes at the same time.

// Object to lock on (to avoid interruption in critical section of code).
private object syncObject = new object();
// Publish a value.
// Note: The data is thrown away if the connection to PubSub is not yet established.
public void Publish(string topic, bool Data, PubSubHeaderData HD, string SecGroup, PubSubSecurityFlag SecFlag)
 {
       lock (syncObject)
       {
            if ((m_Connection != null) && (m_Connection.IsConnected()))
            {
                 m_Connection.Publish(topic, Data, HD, SecGroup, SecFlag);
            }
      }
}

Example code 2

The call to WaitOne will acquire the mutex immediately, if it is not already owned. If the mutex is owned by another thread, the call to WaitOne will pause until the previous thread releases the mutex and the current thread can acquire it. On return from the call to WaitOne, the calling thread owns the mutex and can access the resource it protects. When it has finished accessing the resource, the thread must call the ReleaseMutex method to relinquish ownership.

// Create a new mutex. The creating thread does not own the mutex.
private Mutex _mutex = new Mutex();
// This method represents a resource that must be synchronized so that only one thread at a time can enter.
    private static void UseResource()
    {
        // Wait until it is safe to enter.
        _mutex.WaitOne();
        // Place code to access non-reentrant resources here.
        // Simulate some work.
        Thread.Sleep(500);
        // Release the mutex.
        _mutex.ReleaseMutex();
    }
TitleResults for “How to create a CRG?”Also Available in