标签云

微信群

扫码加入我们

WeChat QR Code

In the application we have something about 30 types of objects that are created repeatedly. Some of them have long life (hours) some have short (milliseconds). Objects could be created in one thread and destroyed in another.Does anybody have any clue what could be good pooling technique in the sense of minimal creation/destruction latency, low lock contention and reasonable memory utilization?Append 1.1.1. Object pool/memory allocations for one type usually is not related to another type (see 1.3 for an exception)1.2. Memory allocation is performed for only one type (class) at time, usually for several objects at time. 1.3. If a type aggregates another type using pointer (for some reason) these types allocated together in the one continuous piece of memory.Append 2.2.1. Using a collection with access serialization per type is known to be worse than new/delete.2.2. Application is used on different platforms/compilers and cannot use compiler/platform specific tricks.Append 3.It becomes obvious that the fastest (with lowest latency) implementation should organize object pooling as star-like factories network. Where the central factory is global for other thread specific factories. Regular object provision/recycling is more effective to do in a thread specific factory while the central factory could be used for object balancing between threads. 3.1. What is the most effective way to organize communications between the central factory and thread specific factories?


Do you know ahead of time the lifetime of the object, or if it will transfer threads?

2019年03月24日40分34秒

Unfortunately no. This is defined by application logic.

2019年03月24日40分34秒

If ctor and dtor do not allocate or free memory, then they should be fast, and thus there should be no reason to avoid them.Also, the issue with having one freelist per-type is that you must use atomic ops to manipulate it, and it will encourage false sharing.

2019年03月23日40分34秒

Not sure that this is the best answer. IMHO the one about tcmalloc was better. Cannot vote though

2019年03月23日40分34秒

Issues with this are that you will see a lot of contention for the stack lock. Also, false sharing will exist, as allocations from separate threads will adjacent. In addition, if 3000 temporaries are allocated, and then 1 permanent object is allocated, the 3000 temporaries will not be reclaimbed.

2019年03月24日40分34秒

I don't get last part about note reclaiming temporary object. Can you be more specific?

2019年03月24日40分34秒

I misread the code and misunderstood the answer; the 'no reclaim temporary' part was entirely wrong. :-) However, the above could be improved to use a linked list, thus removing the lock. (Instead use atomic list ops.)

2019年03月23日40分34秒

Thank you.It was interesting reading.However our guys told me that it has heavy locks contention in compare to umem on Solaris.

2019年03月24日40分34秒

The concept is slightly different. An object could travel through threads handling it. And when its life time will has came to the end it could be in any other thread than the mother-thread. Of course after-life management details are hidden..

2019年03月23日40分34秒