This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mallinfo and scheduler lock


On Tue, Jul 01, 2008 at 09:28:33AM +0200, Riadh Elloumi wrote:
> Dear all,
>
> We are using mallinfo() call to display some statistics on heap usage in  
> our products. But I have noticed that mallinfo locks the scheduler by  
> calling cyg_scheduler_lock (I have seen it in gdb, even if I cannot have  
> all the backtrace because of mixed C and C++). I had a look at the code  
> but don't find when the scheduler lock is called.
>
> Could you confirm this information please? If the scheduler lock is  
> necessary to examine all the heap, it would be helpful to add this  
> information to the documentation, because my understanding is that  
> locking the scheduler will block DSR and threads from execution, and so  
> modify the system behavior.

You might want to look up the Uncertainty principle and the Observer
effect...

Lets first think about this without looking at the code.

There is two ways to implement mallinfo(). Either you walk the complex
linked list of allocated and free blocks, or you keep statistics which
are updated during every alloc and free. 

While walking the lists you definitely need some form of mutual
exclusion, or you are in danger of walking through an invalid pointer
when an list update is going on in another thread. Statistics, if you
really want to trust them, also need locking, otherwise you could see
the same the memory for a block on both the free and allocated list,
or you could not see it at all. Also, keeping statistics is normally a
waste of resources, not many programs will actually use mallinfo(), it
is more of a debug tool.

So i would expect some form of locking, be it a mutex or a scheduler
lock.

In packages/services/memalloc/common/current/cdl/memalloc.cdl you will
find CYGIMP_MEMALLOC_ALLOCATOR_DLMALLOC_THREADAWARE. When this is
enabled, which is the default when the kernel is included in a
configuration, include/dlmalloc.hxx makes use of Cyg_Mempolt2 template
for accessing the memory pool. The alloc template functions is:

// get some memory; wait if none available
template <class T>
inline cyg_uint8 *
Cyg_Mempolt2<T>::alloc( cyg_int32 size )
{
    CYG_REPORT_FUNCTION();
        
    // Prevent preemption
    Cyg_Scheduler::lock();
    CYG_ASSERTCLASS( this, "Bad this pointer");
    
    cyg_uint8 *ret;
    ret = pool.try_alloc( size );
    if ( ret ) {
        Cyg_Scheduler::unlock();
        CYG_ASSERTCLASS( this, "Bad this pointer");
        CYG_REPORT_RETVAL( ret );
        return ret;
    }

    ...
    ...

Above you can see the scheduler lock.

      Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]