Messages in this thread | | | Date | Fri, 09 Apr 2010 11:23:08 +0200 | From | Michael Schnell <> | Subject | Re: atomic RAM ? |
| |
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
| |