Overview of ErrorClass changes in Clarion 6.1

Top  Previous  Next


In Clarion version 5.5 and prior, the Error Class was designed to be a Global class, using just one instance of the class in a program (EXE or EXE with multi DLL) that would be used by the entire application. This was possible because the previous thread model did not allow two different threads to use the global ErrorClass at the same time. With the incorporation of the new thread model in Clarion 6, this limitation disappears, and it is now possible that the global ErrorClass can be used by two different threads at the same time.


In the first release (Clarion 6.0), the ErrorClass was changed to a THREADed Class. This change made it safe to be used in a preemptive thread environment.


There are other possible designs that could have been used. Another approach that could have been taken would be to add thread synchronization to the class. Yet another design approach is to divide the class into two classes: one class contains thread dependent data and the other contains thread independent data. This is the design approach that has been implemented in version 6.1.


If a class has some data that needs to be thread specific and other data that does not, there are several design options that need to be considered.


For thread independent data, a solution is to add some kind of synchronization to the class (e.g., CriticalProcedure) in order to prevent two different threads from accessing these values at the same time. Of course, care must be used in that the data and scope where we use it should maintain this synchronization.


For the thread dependent data, one solution is to move the threaded data to a synchronized queue that stores the data, using the thread number as the queue's key. Another solution (and the one used with Clarion 6.1) is to create a new class (ErrorStatusClass) that is specifically used as a container for the thread dependent data. This second option is equivalent to working with only one class (the ErrorClass) that has threaded and non-threaded parts. The thread dependent part will create and destroy a new instance for each thread and the thread independent part stores the "thread independent ID" of the thread dependent part so it can use it with the associated thread number in order to get the correct reference to the threaded class for a specific thread.


Because any access to the threaded class parts will need to be done using some function that first retrieves the correct class reference, the changes made in the ErrorClass for version 6.1 emulates this implementation, where all access to the key property attributes are now done through an associated pair of GETpropertyname and SETpropertyname methods, where propertyname is the property that is affected.


Sometimes these GET/SET methods are used to wrap the synchronized object, and other times they control the access to the specific threaded class’ properties or queues.


Also, these changes to the ErrorClass simplify its use in multi DLL applications, because the global ErrorClass is consistent for each thread, and synchronization is straightforward.

Also, this change maintains the ability to customize errors in only one place and use them throughout the application. A single queue is used to store the error list, so extra memory is not required by additional threads. All methods are declared in the non-threaded class, so only a single instance of these methods is loaded in memory. Access to the global class is implemented in such a way that the addition of the synchronization methods will not slow down the application’s performance.