[ P.S.: If this email is inappropriate for the general list, please let me know... ] I am presently working on a port of code-libraries which make extensive use of CLN to multi-threaded code (e.g. using OpenMP or explicit "by hand" threading), for use on multi-core and SMP systems. CLN release 1.1.13 is not re-entrant, and as far as I can tell from preliminary evaluation (and a large number of tests which produce major heap corruption), this is primarily because of the non-atomic reference counting (and possibly other mechanisms that I have not yet located). This means that I have the choice of either (a) switching to another, comparable class library (which as you know, probably doesn't exist) or (b) assisting in developing a thread-safe version of CLN. With this latter in mind, is anyone else working on this? If there is already a specification for this transition, please let me know how I can interface with the development work. Please note that this modification is something that I need urgently, and so I can potentially offer quite a bit of work to this project. Thanks! -- Kort Travis Department of Physics, RLM 5.208 University of Texas at Austin Austin, TX 78712 email: kat@physics.utexas.edu
Hello,
I am presently working on a port of code-libraries which make extensive use of CLN to multi-threaded code (e.g. using OpenMP or explicit "by hand" threading), for use on multi-core and SMP systems.
This is a very good idea. OpenMP allows to make use of multiple processors with very little programming effort. And gcc-4.2 will support it.
CLN release 1.1.13 is not re-entrant, and as far as I can tell from preliminary evaluation (and a large number of tests which produce major heap corruption), this is primarily because of the non-atomic reference counting (and possibly other mechanisms that I have not yet located).
You could probably easily replace this with atomic increments and decrements; it's centralized in the three methods cl_inc_pointer_refcount cl_gc_dec_pointer_refcount cl_rc_dec_pointer_refcount in include/cln/object.h. It will need a few CPU specific asms in order to be efficient. Furthermore you have to minimize/eliminate the global variables in cl_low.h. Also some cl_hash* tables might need locking. There are also a few global variables, such as the default precision and the input/output radix. Probably they are only modified at the start of any cln application. All in all, it's quite feasible, because most of CLN is written in a functional style and uses parameter passing on the stack. Bruno
Bruno Haible wrote:
You could probably easily replace this with atomic increments and decrements; it's centralized in the three methods cl_inc_pointer_refcount cl_gc_dec_pointer_refcount cl_rc_dec_pointer_refcount in include/cln/object.h. It will need a few CPU specific asms in order to be efficient.
I would love to know whether this results in performance degrading noticably. If the numbers in <http://gcc.gnu.org/ml/libstdc++/2005-11/msg00099.html> are correct, then it probably won't. However, if the numbers in the post quoted there are correct, then it might make sense to provide a way to turn atomic operations off at configuration time. Apart from that, I'm all in favor of Kort Travis' effort. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
participants (3)
-
Bruno Haible
-
Kort Travis
-
Richard B. Kreckel