Re: atomic RAM ?

[Michael Schnell <mschnell@lumino.de>]

On 04/09/2010 03:36 AM, Mike Frysinger wrote:
> i think you underestimate the task of customizing every userspace
> point that may want atomic instructions.  
I never said this would be easy ;) Maybe it's close to impossible :(

I had hoped modifying the "atomic" macros for the arch in question in a
way that they use a handle instead of a pointer to the "atomic" variable
in a compatible way and then modifying the code that uses these macros
in a way that theses handles are created by additional macros that with
other archs can be uses optionally (in a compatible way: returning the
appropriate pointer) could work. But of course you are correct that a
lot of code would need being inspected.
> and no matter what sized
> atomic region you pick, having it arbitrarily fail at runtime because
> applications have "too many" locks is a poor solution.
>   
Of course you are right, but not being able to allow for SMP is a poor
solution, too.

I suppose it's possible to generate a dedicated system error when an
application runs out of "pthread_mutex" locks (i.e. when the
atomic_malloc() function detects that the atomic RAM is exhausted). You
also can unexpectedly get a normal "out of memory" system in an
application error at any point (e.g. when opening a file) ;) I don't
suppose any "normal" embedded application will use more than some 100.
(In any case, it would be good to have a (of course no-SMP-)
distribution that uses the "atomic region" software workaround, as well,
in case the user does not want to implement the necessary custom
instructions. This would be usable for applications excessively
consuming of "atomic RAM", too.)

-Michael