incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marvin Humphrey (JIRA)" <>
Subject [jira] Updated: (LUCY-91) Atomic memory operations
Date Wed, 30 Dec 2009 18:49:29 GMT


Marvin Humphrey updated LUCY-91:

    Attachment: atomic.diff

This patch probes for atomic support using Charmonizer and provides a common
interface via Lucy::Util::Atomic and the static inline function lucy_Atomic_cas_ptr. 
It takes the following approaches:

  * On Mac OS X 10.4 and later, pound-include libkern/OSAtomic.h and 
    wrap OSAtomicCompareAndSwapPtr().
  * On Windows, wrap InterlockedCompareAndExchangePtr() from windows.h.  Since
    windows.h is such a namespace polluter, we need to hide it away in Atomic.c
    behind a real wrapper function rather than use the function directly within 
  * On Solaris 10 and later, pull in "sys/atomic.h". and wrap atomic_cas_ptr. This is 
    untested, as I do not currently have a Solaris box at my disposal.
  * If the compiler is GCC 4.1 or later, use the atomic builtin 
  * On older unixen, fall back to an inefficient simulation using a pthreads mutex.

Right now, I only expect to need atomic ops when we add new dynamic classes 
to the vtable registry.  Since we won't be calling them that often, performance is not
a major concern, and we don't need to do what some other projects have done and
start writing assembler targeting various processors.

> Atomic memory operations
> ------------------------
>                 Key: LUCY-91
>                 URL:
>             Project: Lucy
>          Issue Type: Improvement
>          Components: Charmonizer, Core - Util
>            Reporter: Marvin Humphrey
>            Assignee: Marvin Humphrey
>         Attachments: atomic.diff
> To make Lucy's OO infrastructure thread-safe, we need support for atomic 
> memory operations -- in particular compare-and-swap-pointer.  Many operating
> systems now provide headers supporting such ops, but we need to provide
> a common interface.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message