Show HN: uThreads – Concurrent User Threads in C and C++ • Hacker News Board

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#61

Post by saman_b » Wed, Nov 09, 2016, 4:18 AM UTC

jcbeard wrote: post #60

saman_b wrote: post #51

Earlier quoted context omitted.

Thanks for mentioning this, it is indeed very related and very interesting. I am not sure why not me or people around me were aware of Qthread, it has very good support for various architectures and provides many interesting features. It has many similarities with I have in mind for a concurrent library, and even some research goals seems to be very close to mine. Specially the notion of affinity and locality is what…

ooh, ok. you might also check out openshmem ( http://openshmem.org/site/ ) and openucx ( http://www.openucx.org ). I'd been planning on integrating both in RaftLib just not enough cycles to get it done yet. These combined would make it much easier to maintain a relatively portable yet performant back end. My thesis research was all about locality, memory placement, and throughput for big data systems. Current work is…

Thanks, so much information to absorb, let me go through all this and get back to you. I shoot you an email when I processed all this :)

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#62

Post by saman_b » Wed, Nov 09, 2016, 4:18 AM UTC

jcbeard wrote: post #60

saman_b wrote: post #51

Earlier quoted context omitted.

Thanks for mentioning this, it is indeed very related and very interesting. I am not sure why not me or people around me were aware of Qthread, it has very good support for various architectures and provides many interesting features. It has many similarities with I have in mind for a concurrent library, and even some research goals seems to be very close to mine. Specially the notion of affinity and locality is what…

ooh, ok. you might also check out openshmem ( http://openshmem.org/site/ ) and openucx ( http://www.openucx.org ). I'd been planning on integrating both in RaftLib just not enough cycles to get it done yet. These combined would make it much easier to maintain a relatively portable yet performant back end. My thesis research was all about locality, memory placement, and throughput for big data systems. Current work is…

Thanks, so much information to absorb, let me go through all this and get back to you. I shoot you an email when I processed all this :)

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#63

Post by CyberDildonics » Wed, Nov 09, 2016, 8:41 PM UTC

rsp1984 wrote: post #39

CyberDildonics wrote: post #33

Earlier quoted context omitted.

Fork and join is one type of concurrency technique, but to think you wouldn't need anything else is silly. Non shared memory concurrency and pipelined concurrency are two more techniques that can be used.

I was stating this in the context of ray tracing. Why not just use OpenMP and be done with it?

I answered that question. OpenMP fork-join concurrency can be useful for certain parts of a ray tracer depending on the overall architecture. It is far from the only way and can have many draw backs when it comes to overhead, synchronization and memory locality.

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#64

Post by saman_b » Thu, Nov 10, 2016, 6:31 AM UTC

naasking wrote: post #59

saman_b wrote: post #54

Earlier quoted context omitted.

Well on the surface, yes! when I started I expected the same. For now there is no work stealing among kThreads. But let me dig into the problem a bit deeper so you get an idea why it might not be very straight forward (also it very much depends on the use case). Usually these libraries either provide their own queue or rely on underlying event system e.g. epoll/kqueue to manage the state of the light weight threads.…

I agree there are additional complexities with M:N. I was assuming a lock-free queue, since you'll need this for scalable work-stealing. I was also assuming a single kernel thread performs I/O via epoll/kqueue/etc. and either has its own queue from which other threads steal, or simply pushes results onto a random queue when requested I/O are complete. This accomplishes the migration I believe you were describing. Whe…

> I was also assuming a single kernel thread performs I/O via epoll/kqueue/etc. and either has its own queue from which other threads steal, or simply pushes results onto a random queue when requested I/O are complete. This accomplishes the migration I believe you were describing.

> When I/O needs to be done, you enqueue the uthread on the I/O queue and invoke a reserved file descriptor to notify the I/O thread, which then reshuffles its file descriptors and again calls epoll/kqueue.

If I remember correctly, what you described is similar to how golang perform I/O polling since they are using work stealing, except there is no dedicated poller thread, and threads take turn to do the polling whenever they become idle.

Also, with epoll/kqueue there is no need to enqueue uThreads and you can simply store a pointer(a struct that has reader/writer pointers to uThreads) with the epoll event that you create and recover it later from the notification, this way you can set the pointer when need to do I/O.

I agree a single poller thread does not scale as well as per kthread epoll instance, and that requires some meditation to provide a low overhead solution that does not sacrifice performance over scalability.