ace/Synch.h sanitizations

[esohns]

ACE implements abstractions for synchronization primitives, supporting platform features and emulating functionality that may not be available natively (e.g. recursive mutexes, absolute/relative timeouts, thread mutexes, (DLL-)singletons, etc). This abstraction is mostly implemented using macros in ace/Synch_Traits.h that translate into type declarations specifying the traits of 'strategized' class templates (e.g. ACE_Task_T, ACE_GUARD) as well as regular class members and variables (e.g. ACE_SYNCH_MUTEX). I.e., rather than specifying a functionality by class, developers use a macro instead (e.g. ACE_SYNCH_MUTEX for ACE_Thread_Mutex). [Notice also how ACE might start to integrate std::mutex using (sets of) configuration macros such as ACE_SYNCH_USE_STD_MUTEX this way]
These type declarations are sometimes templates themselves, leading to issues on some platforms, when the compiler cannot see their definitions at build time. This is being addressed by the meta-header ace/Synch.h, which #includes all necessary declarations in the 'right' order. However, this approach introduces subtle issues (specifically, 'multiple definitions' linkage trouble for the template specializations, using MSVC).
The proposed solution is two-fold:

• replace ace/Synch.h with ace/Synch_Traits.h in all ACE headers, and #includeing ace/Synch.h in each translation unit (.cpp) using any synchronization functionality at all (Note that this is a requirement, as compilers generally will not translate under-defined template classes). Note how this measure effectively moves the issue into each translation unit, where it can be solved individually
• use the concept of extern templates (introduced in C++11) whenever possible

This way, the two-step approach (i.e. pre-processing + strategized primitives) towards abstracting synchronization described above becomes less error-prone and can be developed more easily.

This pull request addresses point one

[esohns]

pulled #320 and resolved the merge conflicts. However, the changes of #176 are now reverted and need to be remerged

[jwillemsen]

We also have other compilers than msvc on windows, probably this has to be specific to the microsoft compiler

[mitza-oci]

See the MPC documentation for how to write a section that only applies to MSVC.

[esohns]

Thank you. Fixed in commit 199cd41

[jwillemsen]

Can you check the systems from which you commit, one seems to use an invalid email address.

[mitza-oci]

Please check .gitignore, the changes don't make sense to me. The semantics of [] are "pick one character from the list."

[esohns]

the changes to .gitignore reflect the fact that the rule *.[ip]db did not filter the .ipdb files generated by recent MSVC compilers. I don't know whether this introduces inconveniences on other systems. Thank you for bringing this to my attention.

[jwillemsen]

Is this necessary?

[esohns]

No. Removed in commit 7723fd6

[jwillemsen]

I see that you add an include of ace/Synch.h to a lot of files, this means that you pull in all possible headers for synchronization which looks an overkill, a lot of time has been spend on making it possible to just include the wrappers needed, now you include everything again, resulting in more compile-time and potential footprint. Is there no other solution?

[esohns]

ace/Synch.h may become obsolete altogether at some point. It was being pulled in indirectly via other headers before this change; I doubt that the compilation time has increased significantly (BTW, does the DOC group keep track of this ?), the footprint has probably changed only a little.
Now that it is included directly only by those translation units requiring synchronization, changes are easier to gradually implement. What you expressed - to effectively only include the wrappers that are actually required, is now feasible. The next step in this direction will require more thought and effort however.

A new set of meta-headers should be introduced to structurize the functionality (i.e. separate mutex/condition, process/thread scope, ...). In this scenario, ace/Synch.h could then be replaced to better include only that particular subset of headers related to the application-/module-/class- or instance-specific strategy being referenced by the set of selected synchronization traits. Note how, in this process, every translation unit needs to be considered separately.

Complementary next steps keep ace/Synch.h as it is today, and start modifying it along the lines of ace/config.h, i.e. structure it through (ACE-) configuration macros, compiler flags or other means, to define particular strategies, which would then effectively translate into an #ifdeffed-inclusion of a subset of all available headers directly.

To me, some combination of these ideas will lead to a good intermediate solution.