Re: My -short- lock-free sequencer class, I want to see your comments
For me, it looks like an overengineered solution to self-inflicted problem.
I suggest to use "single-entered workitem" concept instead.
IOCP threads would simply queue the recv packets in arbitrary order into the
socket context. Then they would either use QUeueUserWorkitem, or
PostQueuedCompletionStatus to execute a handler for that data.
To make sure that at any moment there is only one handler queued or running
for this socket context, use a per-socket LONG flag with the following
states:
0 - no WI is queued or executed;
1 - the WI is queued, not picked for execution;
1 - WI is queued, not picked for execution, more data is queued;
80000001 - WI is currently executing
80000001 - WI is currently executing and there is more data queued to it.
I'll leave it up to you to devise a code to manipulate the flag. There, when
you get IOCP notification for data, you queue the data and check the flag.
If it's >=1, or >80000001, you don't have to do anything; your new data will
get handled. InterlockedIncrement the flag; if it's >80000001 or >1, you
don't have to do anything; your new data will get handled; otherwise it's 1,
queue your workitem. In the workitem, do {} while loop. In the beginning of
the loop, set the flag to 80000001, then handle all data you can handle.
Loop end condition is when your InterlockedCompareExchange(&flag, 0,
0x80000001) succeeds.
The code inside said do{}while loop will deal with all data ordering issues,
by simply resorting the buffers according to their seq#. If it doesn't have
a buffer to close a hole, it will just continue the loop, where it either
exit, or gives the data one more shot.
And yes, such code works. The only synchronization primitives required is
the said flag, and a workitem/DPC/APC facility.
"K?r?at" <kursattheking@gmail.com> wrote in message
news:OerzAgoCJHA.1184@TK2MSFTNGP04.phx.gbl...
The concept is explained in this article by Len Holgate :
http://www.codeproject.com/KB/IP/reusablesocketserver4.aspx
He also impelemented the concept in his free IOCP Socket Server. I only
implement a sequencer as a non-blocking or lock-free algorithm.
"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:%232QshykCJHA.524@TK2MSFTNGP06.phx.gbl...
There is no such concept as "order" when you're talking about two or more
different threads. The completion packets are posted to IOCP queue in
order, they are fetched by threads that call GetQueuedCompletionStatus
sequentially. As soon as the kernel code that's under GQCS function
releases the queue lock, there is no "order" concept anymore. Your code
may happen to call IsInOrder function and get TRUE, and at the next
instance the thread that was "ahead" may now run "behind". If you want
"ordered" processing, you need to handle that in one thread.
"K?r?at" <kursattheking@gmail.com> wrote in message
news:euFZo5gCJHA.1180@TK2MSFTNGP04.phx.gbl...
As a configurable property of my server, it is possible to post more
than one overlapped WSARecv for a given socket at the same time. Those
calls always completes in order but it doesn't mean that they will be
processed in order.
Not my model, the IO Completion Port model needs multiple threads. It
doesn't need multiple threads indeed but using IOCP framework with
single thread is meaningless and completely disables it's advantages.
Anyway, what do you think about the class's correctness without
considering IO related issues?
"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:OOhqGNeCJHA.3576@TK2MSFTNGP05.phx.gbl...
Considering that single socket RX happens always in order, why do you
think you need interlocked operations? Just make sure you get all data
from your socket in the same thread. Describe, why your model need
multiple threads?
"K?r?at" <kursattheking@gmail.com> wrote in message
news:uSW4x$dCJHA.4932@TK2MSFTNGP03.phx.gbl...
Hi,
Recently I needed a sequencer for my IOCP based socket server and
developed one. I try to implement it in lock-free manner. Your
comments will bee appreciated.
The class is very small and all it do is to maintain two numbers in
thread safe manner. Before every WSARecv call I get next available
sequence number from sequencer and put that number into my
PerIoContext object. When a recv completion occured then I check the
sequence number to decide if the completion occured in order. So one
of the two numbers (m_lCurrentSequence) represents call sequence and
the other (m_lRunningOrder) represents completion sequence. Here is
the class :
class Sequencer
{
public:
Sequencer (LONG lMaxSequence) : m_lCurrentSequence (0),
m_lRunningOrder (0), m_lMaxSequence (lMaxSequence)
{
}
LONG getNextSequence ()
{
LONG lCurrentSequence, lNextSequence;
while (true)
{
InterlockedExchange (&lCurrentSequence,
m_lCurrentSequence);
lNextSequence = (lCurrentSequence == m_lMaxSequence ? 0
: lCurrentSequence + 1);
if (lCurrentSequence == InterlockedCompareExchange
(&m_lCurrentSequence, lNextSequence, lCurrentSequence))
{
break;
}
}
return lNextSequence;
}
bool isInOrder (const LONG lSequence)
{
return (lSequence == m_lRunningOrder);
}
bool updateRunningOrder (const LONG lSequence)
{
if (isInOrder (lSequence))
{
// Safe region...
LONG lNewRunningOrder = (lSequence + 1) > m_lMaxSequence ? 0
: (lSequence + 1);
InterlockedExchange (&m_lRunningOrder, lNewRunningOrder);
return true;
}
return false;
}
private:
LONG m_lMaxSequence;
LONG m_lCurrentSequence;
LONG m_lRunningOrder;
};
Thanks in advance for your comments.