Re: [Stlport-devel] Dead-lock in __node_alloc in STLport 5

[<fra...@fr...>]

Thanks Albrecht for this new argument in favor of the lock free node 
allocator implementation :-)


Albrecht Fritzsche wrote:
> Petr Ovtchenkov wrote:
>> The simplest way is to switch to pure malloc-based allocator
>> (-D_STLP_USE_MALLOC).
>
> Oh, thanks - since I don't think that stl containers are
> our bottleneck this might be the first way to go.
>
>> You will lost not-so-much in performance,
>> but avoid two memory managers (one over another), that really
>> has conflict in you case.
>
> Yes, but the only conflict is the static lock in the allocators,
> isn't it? So, why is it static?
>
> > BTW, with node_alloc and technique
>> you use, you target will not be reached---node_alloc don't return
>> once allocated memory to OS scheduler, but reuse it inside
>> application.
>
> Our target (freeing some memory) will be reached nevertheless:
> the destruction of a std::set was just part of flushing out
> some big chunks of data where the std::set was just happen to
> be part of. So, if std::set keeps its memory then the gained
> memory is not as big as theoretically possible but that's ok.
> (This code is part of a [mainly ray tracer] renderer framework -
> film productions and CAD engineers tend to have multiple Gbytes
> of data, hence this handling of otherwise extreme cases.)
>
>> Another possible workaround is replace spin_lock in the _Node_Alloc_Lock
>> by reentrant mutex
>
> That was my first hack on linux - I recompiled the code with
> (sorry for the possible incorrect name) _STLP_DONT_USE_SPIN_LOCK
> and initialized all mutexes as reentrant (something like
> PTHREAD_RECURSIVE). Unfortunately not even main() was reached
> on startup, so probably some static data initialization didn't
> liked my hack ;-)
>
>> I am expect, that the best way will be malloc-based allocator in 
>> STLport,
>> underlaid by Hoard.
>
> Since Hoard is based on per-processor heaps I don't expect any
> performance gains with single processors, but yes, multi-core
> processors are coming right now. I have to re-read some papers
> but IIRC there are already some new allocations schemes (even
> by the Hoard team around Berger, others propose lock-free
> allocations).
>
> Thanks a lot,
> Ali
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Stlport-devel mailing list
> Stl...@li...
> https://lists.sourceforge.net/lists/listinfo/stlport-devel
>
>