*** ThreadKit Beta Release Notes *** The ThreadKit is a complete toolkit for trying to make multithreaded NeXTSTEP programming a little less arcane. It will be released as a commercial product at a very reasonable price when complete. This beta version expires September 31. The ThreadKit consists of four classes, a category and a protocol: * TKThreadLocking Protocol A protocol that defines locking syntax shared by all ThreadKit classes * TKObject Class A subclass of Object that adds the common locking mechanism used by all ThreadKit classes. A TKObject combines the behaviour of the Mach Kit NXRecursiveLock and NXConditionLock classes while adding non-blocking locking methods * Object ( TKThreadLocking ) Category Extends the TKThreadLocking protocol to all every class in your application so that every class you use behaves as if it inherited from TKObject * TKResource Class A subclass of TKObject that manages a pool of named resources, allowing your application to lock and unlock ANYTHING in a thread safe fashion, including non-threadsafe functions like "printf" * TKApplication Class A subclass of Application that allows threads to access AppKit objects and methods with impunity * TKThread Class A subclass of TKObject that provides a mechanism for spawning and controlling autonomous threads --- Two simple examples included demonstrate ThreadKit use, more to come... --- Planned for 1.0 - Finalized API - Better documentation, including an introduction to multi-threaded programming - More examples - Implementation of bright suggestions from the Internet community! Changes in 0.92: - Thread-safe alternative to usleep added to TKThread class - Beta extended to Sept 31 Changes in 0.91: - Proper .pkg installation process - Beta extended to Aug 31 Changes in 0.9: - WARNING: The size of most of the classes have changed. You might as well recompile everything (again) - A bug in the Object category preventing more than one non-threadkit object from being locked at a time (sigh) has been fixed - The locking semantics shared by all classes have been extended to support waiting for particular states - The documentation has been significantly updated - A mechanism for controlling the Obj-C runtime multithreading policy has been added to TKThread Changes in 0.8: - WARNING: The size of the TKObject class has changed. You might as well recompile everything :-) - Suspending threads by locking them was forcing extended busy-waiting that brought the system to its knees as thread priorities were pushed through the roof (more fun to describe than experience). Locks in the ThreadKit no longer busy-wait Changes in 0.7: - WARNING: The size of the TKThread class has changed, as has its superclass. Any subclasses need to be recompiled - Thread control mechanisms (for suspending, resuming, yielding and exiting threads) have been implemented in the TKThread class - Implemented a protocol (ThreadLocking) that TKObject, TKApplication and the ThreadLocking Object category all conform to - A lingering bug that sometimes caused problems with applications that created threads during "awakeFromNib" messages has been fixed (note that this was what caused occasional unpredictable behaviour in the SampleTest demo app) - A mechanism for locking ALL threads to ensure integrity of REALLY dangerous actions (eg: dynamic linking of new classes) has been added to the TKThread class Changes in 0.5: - WARNING: The size of the TKApplication and TKObject classes has changed, any subclasses need to be recompiled - WARNING: For consistency between the growing number of ThreadKit classes and a desire to avoid naming conflicts, all locking and unlocking methods have been renamed "threadLock" and "threadUnlock" respectively - WARNING: For consistency with AppKit methods, the TKThread method "initFor:performing:" has been renamed "initFor:perform:" - Trying to lock the appkit from the main thread is now harmless - Added locking semantics to ALL objects through the Object(ThreadLocking) category - Added named resource locking via the TKResource class - The "tryThreadLock" method has been added to all classes in order to attempt locking with non-blocking semantics Changes in 0.2: - Class names changed to shorten names and prefix all ThreadKit classes with "TK" - More robust error checking (now only the thread that locked the AppKit can unlock it!) - Threads are discarded properly when finished - Nested locking of TKApplication is now supported - Real documentation written & included - The Objective-C runtime is now made thread-safe only when more than one thread is running - Changes to the "SortingInAction" example code to use the ThreadKit are supplied. See ThreadKit/Samples/SortingInAction/README for details - Beta period extended to July 31 Changes in 0.11: - Now supplied in single-architecture as well as multi-architecture form for those running 3.0 --- Feel free to write with comments, suggestions, criticisms. Whatever. Blake Stone 219 Edgevalley Mews N.W. Calgary, Alberta, Canada T3A-5E5 bstone@acs.ucalgary.ca