1

I know that asynchronous socket programming is more scalable than synchronous.

But there is one thing I don't really understand about it:

If your event loop should be non blocking, how can you delegate time consuming work to another thread without blocking? A work queue normally needs a mutex for protection. I know there are lock free queues but is this how its done? Can someone please give a little concept idea of this thing?

Marco
  • 7,007
  • 2
  • 19
  • 49
  • You just split the long work into a sequence of short snippets. Read about [CPS](https://en.wikipedia.org/wiki/Continuation-passing_style) which might give the theoretical insight. – Basile Starynkevitch Oct 25 '14 at 17:03
  • @BasileStarynkevitch and how exactly does this solve the problem? – Marco Oct 25 '14 at 17:03
  • Queue the context data to the other thread/pool. Queue it back again when done so that a callback is fired for it and with it. Isn't ASIO fun:) – Martin James Oct 25 '14 at 18:22
  • @MartinJames but this would require a mutex, wouldn't it? – Marco Oct 25 '14 at 18:31
  • @HansPassant My problem is: the event loop should be nonblocking, but a task queue would require a mutex, so there is a chance that it will block the event loop, which is bad. – Marco Oct 25 '14 at 18:49
  • You can have many threads pumping the same event loop. For example, with epoll you set each file descriptor to "one-shot", and then you can throw as many main epoll loops at your problem as you need. – Kerrek SB Oct 25 '14 at 18:59
  • @KerrekSB By pumping the same event loop do you mean that multiple threads "read" from the same kqueue? – Marco Oct 25 '14 at 19:03
  • @d3l: I'm not familiar with kqueue, but I imagine that this should be possible. On Linux, epoll is definitely designed to allow this, i.e. the epoll system call is handled correctly by the kernel (which will report a given event to precisely one polling thread). That doesn't mean that this should be your sole mechanism of concurrency, and handing work off to a worker thread pool is still a viable idea, but I'm just saying that you can even do the main event loop with more than one thread if that helps. – Kerrek SB Oct 25 '14 at 19:10

1 Answers1

1

The worker threads pulling from the queue block all the time. They have to when the queue is empty. What else are they supposed to do?

It is the work items that are not supposed to block so that we need just a few queue worker threads.

Async IO is about using less threads.

If your event loop should be non blocking

This assumption is false. It is not supposed to not block. The loop contains blocking all the time. Every time the queue is empty and a worker tries to dequeue.

usr
  • 168,620
  • 35
  • 240
  • 369
  • The event loop runs on one or more worker threads. What exactly is not answered? – usr Oct 25 '14 at 19:02
  • I was taught there should be only one thread pulling from the kqueue or a mix of a thread pool and kqueue. – Marco Oct 25 '14 at 19:05
  • You can do it with one thread if you want. The answer still fully applies. What exactly is not answered? There must be some misunderstanding here and you need to cooperate to find it. – usr Oct 25 '14 at 19:06
  • I don't know how to delegate work from the event loop to another thread without blocking the event loop (if I have only one event loop). I'm very unsure about how a asynchronous tcp server would look like in concept. – Marco Oct 25 '14 at 19:09
  • Event loops make sense if the work items do not block. If a work items want to execute an IO operation it starts the operation and makes the operation queue another workitem when the IO is completed. The old workitem returns. And while the IO is in flight no work item is running or queued at all (that relates to that IO). – usr Oct 25 '14 at 19:25