Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Mar 2012
Offline Last Active Yesterday, 05:32 AM

Posts I've Made

In Topic: Unreal Engine 4 Velocity From Distance + Gravity

Yesterday, 05:33 AM

Found a solution from https://forums.unrealengine.com/showthread.php?58157-TUTORIAL-BP-Jump-Pad-only-adjust-Destination-Point-Not-Beginner-friendly-atm

Works perfectly fine ;-)

In Topic: Single producer - multiple consumer fast queue?

21 June 2016 - 11:09 PM

Can't the queue just contain pointers to these large 300kb packets?


Then you can use a fast SPMC queue of pointers, and separately, a lock-free pool allocator of the packets themselves.


Oh this may work, i will give it a try.

In Topic: Single producer - multiple consumer fast queue?

21 June 2016 - 12:55 PM

How much memory do you need to copy? Because you would have to literally be copying several GB worth of data per second to show up as a problem. Unless this is the case, it sounds to me you're hitting false cache sharing issues while doing the copy, which would slowdown all cores considerably.


Hmm after analyzing, it happens to be around ~300 kb at max for a packet. So you are basically right - there is too much going on. Back to the drawing board.

In Topic: Single producer - multiple consumer fast queue?

21 June 2016 - 10:28 AM

First step: Write a lock based one, or better yet, use an existing queue such as ConcurrentQueue, which is already moderately lock free (source).
Second step: If profiling actually shows it to be a problem, then invest the time to replace it.


As for writing a lock free circular queue goes, for starters: Time consuming operations should be completed long before you ever attempt to insert the object into the queue. Your insertion into the queue should be one or more CAS operations based on the result of the CAS.


The queue itself is not the problem, but the fixed memory used for the queue entries and the process of copy the memory into the slot.

Adding or removing from the queue works just fine. Seems i need another lock for each entry to solve this problem - so a decoder can dequeue but waits until the memory is finished.

In Topic: C Queue Linked List madness

20 June 2016 - 01:01 AM

There is a mistake in dequeue method ..you need to do temp = temp->next;
then free(first); first = temp;
You are freeing the second element each time and if free->next is null then it will crash.


This is almost exactly what this implementation do, but it first checks if there is a next pointer and then assign it back to the first and on the else case it just sets the first and last to Zero. Ah and i dont need to free any memory - because i use a pre-allocated memory system where all memory is allocated once at start up and released when the application is done. No Need for alloc or free while the app is running ;) Just PushSize, PushStruct, PushArray, etc.