the availability of functionality is set by the header files for each
platform, not by configure. So we'd have to play some games to get
at the information, but it should be possible.
On Jul 14, 2007, at 12:41 PM, George Bosilca wrote:
> We should be able to use these defines in the configure.m4 files for
> each component right ? I think the asm section is detected before we
> go in the component configuration.
> So far we know about the following components that have to disable
> themselves if no atomic or memory barrier is detected:
> - MPOOL: sm
> - BTL: sm, openib (completely or partially?)
> Anybody knows about any other components with atomic requirements ?
> On Jul 14, 2007, at 1:59 PM, Brian Barrett wrote:
>> On Jul 14, 2007, at 11:51 AM, Gleb Natapov wrote:
>>> On Sat, Jul 14, 2007 at 01:16:42PM -0400, George Bosilca wrote:
>>>> Instead of failing at configure time, we might want to disable the
>>>> threading features and the shared memory device if we detect
>>>> that we
>>>> don't have support for atomics on a specified platform. In a non
>>>> threaded build, the shared memory device is the only place where we
>>>> need support for memory barrier. I'll look in the code to see
>>>> why we
>>>> need support for compare-and-swap on a non threaded build.
>>> Proper memory barrier is also needed for openib BTL eager RDMA
>> Removed all the platform lists, since they won't care about this
>> part :).
>> Ah, true. The eager RDMA code should check that the preprocessor
>> symbol OPAL_HAVE_ATOMIC_MEM_BARRIER is 1 and disable itself if that
>> isn't the case. All the "sections" of ASM support (memory barriers,
>> locks, compare-and-swap, and atomic math) have preprocessor symbols
>> indicating whether support exists or not in the current build. These
>> should really be used :).
>> devel mailing list
> devel mailing list