All the refrence counting is done with thread safe code. This means several threads can hold handles to the same object safely. This allows thread safe code to be written easily, provided your carefull.
This is not to say that all methods on RAVL objects are thread safe. It is up to the user to ensure access to objects within
their programs is handled in a an appropriate manner.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So that mean that, basically, only the operator= for reference counted classes is thread-safe. As to all other functions of the classes a programmer should think about thread-safeness. Am I right?
And about thread-safeness of all classes, which do not have reference counting mechanism, a programmer should care too. For example, the StringC class has no advatages if compared with the string class in STL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not quite. More important than the operator= and a thread safe copy constructor, is the class destructor. This ensures the body destructor is only called by one thread. Especially as its very difficult to control when a destructors are called.
StringC uses thread safe refrence counting to avoid uneeded copying, as do some implementations of the STL string. The
exact behavour of each the implementation may vary. The behavour of the RAVL implementation will not.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I understand all thread-safeness of reference counting is in Atomic.hh file. The Generic version of the file is not thread-safe. I actually don't know is the version been used somewhere.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The only time the generic headers are used is when no machine specific implementation available. As many RAVL programs don't use threading, this is still usefull for many applications
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've heard that it is. But I fail to find any mutex-like operations in StringC class for example. What makes RAVL more thread-safe than STL?
All the refrence counting is done with thread safe code. This means several threads can hold handles to the same object safely. This allows thread safe code to be written easily, provided your carefull.
This is not to say that all methods on RAVL objects are thread safe. It is up to the user to ensure access to objects within
their programs is handled in a an appropriate manner.
So that mean that, basically, only the operator= for reference counted classes is thread-safe. As to all other functions of the classes a programmer should think about thread-safeness. Am I right?
And about thread-safeness of all classes, which do not have reference counting mechanism, a programmer should care too. For example, the StringC class has no advatages if compared with the string class in STL.
Not quite. More important than the operator= and a thread safe copy constructor, is the class destructor. This ensures the body destructor is only called by one thread. Especially as its very difficult to control when a destructors are called.
StringC uses thread safe refrence counting to avoid uneeded copying, as do some implementations of the STL string. The
exact behavour of each the implementation may vary. The behavour of the RAVL implementation will not.
As I understand all thread-safeness of reference counting is in Atomic.hh file. The Generic version of the file is not thread-safe. I actually don't know is the version been used somewhere.
The only time the generic headers are used is when no machine specific implementation available. As many RAVL programs don't use threading, this is still usefull for many applications