[oneDPL][tbb] + memory leaks fix (sort/stable sort, tbb backend) #1589
Conversation
MikeDvorskiy
added
the
follow through
MikeDvorskiy
force-pushed
the
dev/mdvorski/tbb_backend_mem_leaks_fix
branch
from
4137697
to
420acf8
Compare
| auto __refcount = --__parent->_M_refcount; | ||
| __alloc.deallocate(this, *__ed); |
There was a problem hiding this comment.
Is there a reason we have to decrement the refcount of the parent before we deallocate the child memory?
If not, couldn't we just move the deallocation call outside the if and simplify this code?
There was a problem hiding this comment.
@pavelkumbrasev,
Could you please answer that question?
There was a problem hiding this comment.
I believe it is some sort of an optimization (Used in several TBB patterns) where deallocation can be done concurrently (the reference reached 0 and the thread can proceed with tree folding without waiting for task deallocation on another thread).
I think the benefit is really small so we can amend the optimization and use @danhoeflinger suggestion if it helps with readability.
There was a problem hiding this comment.
If it is faster to do it this way I wont object. It may be worth adding a comment to make that clear going forward.
The difference in readability is minor. However, from someone unfamiliar with the code to start with, it makes it seem like there are more hidden connections which require this pattern.
There was a problem hiding this comment.
I've added a comment.
Co-authored-by: Alexey Kukanov <alexey.kukanov@intel.com>
The main offender is TBB whose parallel sort has memory leaks oneapi-src/oneDPL#1589 so now, the parallel sorts need to be explictely enabled.
The main offender is TBB whose parallel sort has memory leaks oneapi-src/oneDPL#1589 so now, the parallel sorts need to be explictely enabled.
[oneDPL][tbb] + memory leaks fix (sort/stable sort, tbb backend)