geant4: adding a variant for multithreading

[patrick.sizun@…]

Since release 10.0, Geant4 includes support for multi-threaded Geant4 applications. The attached patch would add a variant to enable this feature.

[ryandesign (Ryan Carsten Schmidt)]

Note that the Cc field requires complete email addresses, and that you should use the haspatch keyword when you are providing a patch.

[mojca (Mojca Miklavec)]

Just a few questions: is this only supported in 10.0 or also in 9.6 (9.5)? I need to check anyway, but maybe you know that already.

Is there any penalty/drawback if multithreading gets supported by default and without any extra option?

[mojca (Mojca Miklavec)]

Sorry, you already answered the first question. I just need to make sure that the option is only enabled for 10.0 then.

[patrick.sizun@…]

Replying to mojca@…:

Is there any penalty/drawback if multithreading gets supported by default and without any extra option?

Not according to the release notes:

Existing (or new sequential) applications can be built and run without code changes, on either a sequential and a multi-threading capable installation of Geant4 - provided, of course, that mandatory changes are made to address other migration issues.

[patrick.sizun@…]

Replying to patrick.sizun@…:

Replying to mojca@…:

Is there any penalty/drawback if multithreading gets supported by default and without any extra option?

Not according to the release notes: Existing (or new sequential) applications can be built and run without code changes, on either a sequential and a multi-threading capable installation of Geant4 - provided, of course, that mandatory changes are made to address other migration issues.

However, since the default build of Geant4 is sequential, I think it would be best to do the same for the port for now and only enable the multi-threading if required by users.

[mf2k (Frank Schima)]

I would suggest that the variant be called "threaded" to match other ports like tcl.

[mojca (Mojca Miklavec)]

Speaking about compatible variant names ... here's what a grep for thread returns in other port variants:

boost:     variant no_single  description {Disable building single-threaded libraries}
gauche:    variant no_threads { configure.args-delete --enable-threads=pthreads }
raxml:     variant pthreads   conflicts hybrid description {Pthreads implementation}
cherokee:  variant no_pthread description {Disable threading support}

sbcl:      variant threads    description {Enable multi-threaded runtime using the Mach pthreads interface.}
tcl:       variant threads    description {add multithreading support}
yap:       variant threads
abinit:    variant threads    description {Build with support for multi-thread support (openMP)}
openmpi:   variant threads    description {enable threads for MPI applications}
wannier90: variant threads    description {Build with threaded ATLAS}

hdf5:      variant threadsafe description {Enable threadsafety (experimental, fails unit-tests)}

octopus: # variants: berkeleygw, openmp, threads (for fftw, atlas?), scalapack, arpack

Did you mean +threads or +threaded when talking about Tcl?

Indeed the keyword +threads seems to be the winner, but it also looks like some ports might need some clean up to get rid of those no_* variants.

[mf2k (Frank Schima)]

I'm guessing that my comment was the victim of auto-correct. :) "+threads" definitely is in line with most other ports and we should standardize on that variant name.

[mojca (Mojca Miklavec)]

Committed in r120014.