Thread pitfalls

A thread can be supended at any time, probably when part way through some activity, to let another thread run for a timeslice. Another thread within the same process may then be started, and being unaware of what the first thread was doing may start to utilise a resource that the first thread was utilising. This might be a file, a variable, the printer or anything manipulated by the program.

Most activities are not thread-safe as they involve getting something, doing something with it and putting it back changed. Such things are incrementing counters, testing then setting flags etc. Such activities are termed non-atomic as they do not consist of a single operation and so are interruptable by the Operating Systems' thread scheduler. These operations may be made "thread-safe" by various locking mechanisms and this library provides such a mechanism to enable thread-safety to be achieved.

This mechanism is the set of "RunLocked" methods which allow a Sub to be run "locked" so that it can complete, uninterrupted, non-atomic activities. The normal use for this would be to check a Boolean flag representing some resource to see if it was false and if so set it true to claim that resource. It would also be prudent to lock the reverse activity of freeing the resource, by setting the flag to false, as many Basic4PPC operations are string based and so non-atomic even though they may appear to be atomic.

Threads may be either Foreground threads or Background threads. The only difference between them is that when the process owning them terminates Background threads are forcibly stopped whereas Foreground threads run until they terminates themselves. This library marks threads as Background by default and, although possible, it is not recommended to make them Foreground threads. Once a process has stopped then communicating with a leftover Foreground thread is not possible and the thread may stay in existence until the computer is shut down taking up space and processing power unnecessarily. There may be certain very specific instances where an application wants this behaviour but it is rare, at least for the types of application likely to be written in Basic4PPC.

Threads can have five priorities. Lowest 0 : BelowNormal 1 : Normal 2 : AboveNormal 3 : Highest 4. By default threads have priority 2 - Normal. It is not recommended to increase priority unless there are pressing reasons to do so as higher priorities can hog the computer and may cause problems for the main thread of an application. Lower priorities cause few problems but at "busy" times may have little opportunity to run.

Operations on GUI controls are not thread safe so only the main GUI thread can safely manipulate the user interface. This can cause a problem as it is often convenient for threads to manage part of the user interface for themselves. However Basic4PPC knows this and actually runs all events, even non-GUI related ones, on the GUI thread. Therefore a thread must use an event if it needs to do GUI operations and this library enables that. It is important to know that the thread is suspended until the event code completes and only then then carries on. If anything happens to block the main thread it might also block another thread that has called an event and is waiting for that event to run to completion on the main thread.