Release notes

                      Wefts++ Threading library 0.9

                           - RELEASE NOTES -

                          Giancarlo Niccolai


Issuing a minor number release in less than two weeks may sound bold to
many readers. The fact is that, in this period, I have been helped by very
experienced people that gave me a hand in finetuning the things that I had
made, and gave me interesting idea that are a crucial add to Wefts.

I wish to thank here Kelly Brock for the idea that gave origin to the OS
Threading Abstraction Layer, Alexander Terekhov and David Butenhof for their
useful replies and advices, and all the people at comp.programming.threads
newsgroup.

What you'll find in this release?

- Improved functionalities

- Exception system (with 5 exception classes).

- Finetuned Grammar

- More classes: XMutex, RingBuffer<> and ThreadPtr<> template class.

- OS Threading Abstraction (and Independence) Layer ( OSTAiL )


It must be state here that this release is not yet deeply tested;
it must be considered a "developer's" release, and many features
have undergone just a few tests, that for how they may be
extensive and rough, are not to be considered "proving" as a direct
experience on production field.


Improved Functionalities
========================

* Many bugfixes in Subscription class; now works reliably.

* Cond class has been transformed in Condition, and made available. This
  makes possible to build personalized Mutex + Condition schemes, as well
  as use Conditions in a pthread-like fashion.

* Internal architecture of readwrite mutexes has been rethought, improving
  efficence by using two condition to signal independently readers and
  writers. Also, whenever possible, the conditions are signaled only when
  is demonstrable that there are threads waiting on them.

* Complex mutexes as well as Subscriptions are now fully cancelable, and
  can be also timed;

* Almost all non-basic types support tryLock() semantics.



Exception system
================

Error handling is now done throwing exceptions. The basic system is draw, with
five basic exceptions (four available and the base Wefts:Error class); support
for OS Dependant error messages is provided; support for internal error reporting
is still missing (but is incoming).



Finetuned Grammar
=================

Many method names and prototypes have been redesigned, in the light of achieving
a more natural programming style. Many candy grammar proxies have been added,
expecially regarding the timed subscribe* calls in Subscription.



More classes
============

- XMutex is a mutex implementing the most advanced mutex semantics, as
  recursiveness, trylocks, timed lock() requests and cancellability while
  locking. Basically it is a "downgraded" RRWMutex; instead of being
  forced to use less functionalities than provided in the RRWMutex, the
  user can now decide to use this more efficient class.

- RingBuffer<typename _T> is a template class implementing Producer/Consumer
  model. Threads can write and read asynchronously data drom the ringbuffer
  (using the variable type that they prefer to exchange data).

- ThreadPtr<> is a template class implementing a thread-specific pointer
  semantic. Thread ptr can point to an object and be used in operations
  like dereference, assignments, equality tests but its value is different
  in each thread, so that in the Thread A the pointer can point to var X,
  while in thread B it may point to var Y. This is useful to build application
  specific classes holding common (synchronized) data as well as specific
  data.



OS Threading Abstraction and Independence Layer ( OSTAiL )
==========================================================

OSTAiL is a set of well-defined base classes having a pre-defined
structure and interacting directly with the low level threading API,
or with the OS. OSTAiL classes are then derived into OS Specific
classes, and finally the OS Specific classes are included into the
final application via a typedef alias.

In example, an OSThreadBase class defines the basic interface that
all the OS interfaced tread class must provide to Wefts. Then, this
class is derived by OSThreadPthread, that interfaces the OS Threading
abstraction with the pthread library; finally OSThreadPthread is
aliased into OSThread and included in the application, where it is used
by Wefts::Thread and may be also used by the user application.

In this way, each OSTAiL implementation module is actually a "driver"
providing Wefts with the objects and the functionalities it needs to
work.

The correct OSTAiL module to be linked is determined by the configure
scripts, or by other means available on the target architecture. A
module must be inlined (included as an header file) as long as it is
possible and convenient.

OSTAiL specifications are still not completed or definitely enunciated.
In the documentation, there are many concepts spread a little here and
there, but a formalization is already under way. For a preview, it can
be said that the specifications are somehow similar to a very small
subset of the pthread model, (the smallest subset possible), but differ from
it where the pthread model is not adequate to be represented in an
object oriented language, or would be extremely difficult to be ported to
other architectures. In example, even the OSThreadPthread class is
not roughly a blind wrapper, but does some elaborations on his own to
adapt the pthread library to the OSTAiL model.


---------------------------

Enjoy Wefting!

Giancarlo Niccolai