Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix double free and double alloc #1

Conversation

psychocoderHPC
Copy link

Equally to ComputationalRadiationPhysics#45 this PR should solve the possible double free and double alloc.

@psychocoderHPC
Copy link
Author

btw if you merge this the changes will be directly visible in your PR aginst the mainline.


release_chunk(chunk);
else
chunk->next_item.fetch_sub(1);
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since we increase a 64bit pointer there should be no strong need to add this overflow guard here.

{
*next_item = item;
chunk->last_item ++;
if( (uintptr_t)next_item == (uintptr_t)(chunk_end - 1u))
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be moved to the position before the item is copied to provide faster new memory to other threads.

@michaelsippel michaelsippel force-pushed the topic-chunkedlist branch 2 times, most recently from 6933ef3 to 8897117 Compare December 12, 2023 17:28
Equally to
ComputationalRadiationPhysics#45 this
PR should solve the possible double free and double alloc.
@psychocoderHPC
Copy link
Author

@michaelsippel I rebased this PR against your latest changes and solved the conflicts.

Copy link
Owner

@michaelsippel michaelsippel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good, discussed optimization will be a follow up

@@ -424,7 +417,9 @@ struct ChunkedList
public:
ChunkedList( Allocator && alloc )
: chunks( std::move(alloc), T_chunk_size * sizeof(Item) + sizeof(Chunk) )
{}
{
chunks.allocate_item();
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I currently don't know how much the impact is, but this will decrease the speed of task-creation since every task will create four events , each containing a ChunkedList<EventPtr> to store the list of outgoing edges, but not all Events will actually have outgoing edges (this is also described in Issue ComputationalRadiationPhysics#42 . Maybe, to avoid this a possible condition for allocating a new chunk would be next_item == chunk_end ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

next_item == chunk_end

I think if you use this more than one thread can create the first chunk. Thats the reason why I added it to the constructor because this was the only point where I was sure that there will be no data race.

@michaelsippel michaelsippel merged commit b22c4a9 into michaelsippel:topic-chunkedlist Dec 13, 2023
1 check passed
@psychocoderHPC psychocoderHPC deleted the fix-doubleFreeAndAlloc branch December 13, 2023 13:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants