Reuse, not rework

License Awareness

Highly Reusable Software

By activity
Professions, Sciences, Humanities, Business, ...

User Interface
Text-based, GUI, Audio, Video, Keyboards, Mouse, Images,...

Text Strings
Conversions, tests, processing, manipulation,...

Integer, Floating point, Matrix, Statistics, Boolean, ...

Algorithms, Memory, Process control, Debugging, ...

Stored Data
Data storage, Integrity, Encryption, Compression, ...

Networks, protocols, Interprocess, Remote, Client Server, ...

Hard World
Timing, Calendar and Clock, Audio, Video, Printer, Controls...

File System
Management, Filtering, File & Directory access, Viewers, ...

This page is not a multi-threaded programming tutorial. It is to provide an overview of librock thread safety strategies.

The basic requirement which must be satisfied for thread safety is that if there ever can be multiple, simultaneous execution paths which could write to the same memory object, locks must be used to ensure that only all readers or one writer will access the memory at a time.

When a function uses only local variables, has no pointers passed in as arguments, and makes no external calls, it is generally-thread safe. But these requirements are so restrictive that they are met only very rarely.

For memory objects which are read-only (initialized at run-time startup, or before any second thread starts) no locking is necessary.

For memory objects which are "private" to a thread, and never exposed to other threads, no locking is necessary. This would include some objects on the thread execution stack and objects allocated specifically to the thread. Very special attention must be given if any pointers to those objects are created, and passed as arguments or stored in other objects. This could create persistent references somewhere as a side-effect, and thereby expose those objects to other threads. Those objects are not safe to consider private.

Any other objects should be considered shared, and a lock of the object (or some encapsulating object) must be used before writing AND reading. For performance and deadlock-avoidance reasons, it is usually better to assume a caller did locking on all pointers passed into a function as arguments, although functions specifically designed to ensure thread-safety may do locking within a function. For functions which access shared global variables, the function documentation will note who has responsibility for locking. If the documentation is silent on the subject, then locking is up to the caller.

Identifying thread-safety issues caused by function-calls is aided by the <USES> section of the librock function documentation. It is possible to use semi-automatic dependencies checking, to find that a function could result in a call to malloc() for example. [<A HREF=dependency.html>More on this</A>]

req-DEBUG: edit this