CoCoA » CoCoALib

• an RAII class for "local" rings
• an explicit "destroy" command for rings

John Abbott wrote:

No doubt the problem is due to the temporary rings (inside Elim) not self destroying when they're no longer needed -- ref counting is disabled when the threadsafety hack is forced.

Elim (and a few other functions) create a temporary ring.
I think we should have a way to destroy a (temporary) ring to be called at the end of the function. In fact it would do nothing when ref counting is on (just check it is really destroyable).
The only danger is that inside a child call a global variable (bad for thread-safety anyway) is defined, is that correct?

Anna Maria Bigatti wrote:

Elim (and a few other functions) create a temporary ring.

Yes. Temporary rings are a common idiom. It would be nice to have an easy way of handling them correctly (probably via RAII).

I think we should have a way to destroy a (temporary) ring to be called at the end of the function. In fact it would do nothing when ref counting is on (just check it is really destroyable).

This is what the RAII approach should do.

The only danger is that inside a child call a global variable (bad for thread-safety anyway) is defined, is that correct?

Anna clarified this last comment: the "danger" is that an incautious programmer could leave an element of the temporary ring in a global variable, which would then lead to "undefined behaviour" when that global is altered. The solution is easy: don't use globals :-)

I wonder whether the default configuration for CoCoALib should be the threadsafe one (which incurs a run-time efficiency penalty).

Currently the default is not threadsafe.

What do you think?

After looking around on internet it seems that C++98 has no portable way of dealing with threadsafety, but C++11 (and later versions) does.

Probably the "threadsafe hack" should be migrated to a proper threadsafe option, presumably controlled by a pre-compilation flag CoCoA_THREADSAFE. This implies that default compilation (without setting that flag) would be only single-threaded. Setting the option also implies that compilation is of C++11.

I spoke to Mario this morning about threadsafety in CoCoALib (also thinking about Mario's new code which has just been adjoined to the CVS repository).

Mario liked the idea of a single flag, tentatively called CoCoA_THREADSAFE, which when set will produce threadsafe code (but which also requires a C++11 compiler); if the flag is not set then the resulting executable is not guaranteed to be threadsafe, but it should be possible to compile with a C++03 compiler (for the time being).

Comments? Suggestions? Other ideas?

I wonder whether CoCoA_THREADSAFE is to be just a temporary measure. Presumably at some point practically all compilers will accept C++11. The main question would then be whether the threadsafety measures incur a significant run-time cost during single-threaded execution; if not, then presumably the preprocessor flag will no longer serve any useful purpose (except perhaps for obfuscated code competitions?).

I now think that it is probably better to default to threadsafe code; the user must configure with "not threadsafe" to obtain (presumably faster) non-threadsafe compilation.

Note that when releasing CoCoA-5 we can opt for the "fast, not threadsafe" compilation since CoCoA-5 itself is single-threaded.

If we do follow this proposal, what should the "not threadsafe" option be called?

• non-threadsafe took about 14.7s to run all the tests in src/tests/
• threadsafe took about 16.1s

So for this 1 test suite, threadsafe was about 10% slower.

I would expect that some computations with many ring elems in a small finite field could incur a significantly greater overhead.
So it is likely worth offering a way to compile non-threadsafe code.

• MemPool, OrdvArith, SmartPtrIRC, NumTheory-prime.C, PPMonoidOV.C

Rectifying NumTheory-prime.C might be time-consuming (currently it is unsafe).