Oleh Derevenko(deleted)
|
Unblock pulse with multithreaded RM
|
Oleh Derevenko(deleted)
08/07/2009 6:36 AM
post35434
|
Unblock pulse with multithreaded RM
From own experience I can say that recvid-s are often reused. That is, it's common to receive next request with the same
recvid as the previous one.
In such a situation, how is it possible to implement unblock pulse handling in multithreaded resource manager? For
example thread A receives a read request and starts processing it. A bit later thread B receives unblock pulse for
request being handled in thread A. Let it aside that unblock request can be delivered to user-provided callback even
before the read request itself. But how can the unblock handler be sure that in the time it was prepared to be called,
thread A did not successfully reply to its read recvid and did not accept the next request with the matching recvid? How
can the handler know it's going to abort the correct request?
|
|
|
Sean Boudreau(deleted)
|
Re: Unblock pulse with multithreaded RM
|
Sean Boudreau(deleted)
08/07/2009 9:48 AM
post35451
|
Re: Unblock pulse with multithreaded RM
On Fri, Aug 07, 2009 at 06:36:37AM -0400, Oleh Derevenko wrote:
> From own experience I can say that recvid-s are often reused. That is, it's common to receive next request with the
same recvid as the previous one.
> In such a situation, how is it possible to implement unblock pulse handling in multithreaded resource manager? For
example thread A receives a read request and starts processing it. A bit later thread B receives unblock pulse for
request being handled in thread A. Let it aside that unblock request can be delivered to user-provided callback even
before the read request itself. But how can the unblock handler be sure that in the time it was prepared to be called,
thread A did not successfully reply to its read recvid and did not accept the next request with the matching recvid? How
can the handler know it's going to abort the correct request?
There has to be some synchronization at the rcvid level
in the manager (locking of ocb etc) but that has to be
there for other things other than the handling of unblock
pulses. Then you can verify there's actually an unblock
pending on the rcvid with MsgInfo() looking at the
_NTO_MI_UNBLOCK_REQ flag in info.flags.
Regards,
-seanb
|
|
|
Oleh Derevenko(deleted)
|
Re: Unblock pulse with multithreaded RM
|
Oleh Derevenko(deleted)
08/07/2009 10:26 AM
post35461
|
Re: Unblock pulse with multithreaded RM
>
> There has to be some synchronization at the rcvid level
> in the manager (locking of ocb etc) but that has to be
> there for other things other than the handling of unblock
> pulses. Then you can verify there's actually an unblock
> pending on the rcvid with MsgInfo() looking at the
> _NTO_MI_UNBLOCK_REQ flag in info.flags.
I don't see how this can help. You can check if unblock is pending yet and wait until pulse is handled if you find that.
But you can't check if unblock is going to appear in future. And since you can't make calls to MsgInfo and following
MsgReply to be atomic together you can't guarrantee that the unblock pulse won't be received after you call MsgInfo()
but before you call MsgReply(). And if that happens we are back with original problem: how should unblock pulse handler
in thread B know that recvid recorded in OCB is indeed the recvid it was intended for and not the next request that has
been accepted by thread A after original request had been successfully replied?
|
|
|
Oleh Derevenko(deleted)
|
Re: Unblock pulse with multithreaded RM
|
Oleh Derevenko(deleted)
08/11/2009 8:24 AM
post35663
|
Re: Unblock pulse with multithreaded RM
> >
> > There has to be some synchronization at the rcvid level
> > in the manager (locking of ocb etc) but that has to be
> > there for other things other than the handling of unblock
> > pulses. Then you can verify there's actually an unblock
> > pending on the rcvid with MsgInfo() looking at the
> > _NTO_MI_UNBLOCK_REQ flag in info.flags.
>
> I don't see how this can help. You can check if unblock is pending yet and
> wait until pulse is handled if you find that. But you can't check if unblock
> is going to appear in future. And since you can't make calls to MsgInfo and
> following MsgReply to be atomic together you can't guarrantee that the unblock
> pulse won't be received after you call MsgInfo() but before you call MsgReply
> (). And if that happens we are back with original problem: how should unblock
> pulse handler in thread B know that recvid recorded in OCB is indeed the
> recvid it was intended for and not the next request that has been accepted by
> thread A after original request had been successfully replied?
So, do you confirm that unblock handler can't be reliably implemented if there is more than one thread in RM? You've got
to do something with that - it's used everywhere.
For me it's a great luck that I only used single-threaded RM's so far. But I need unblocking and I may need more than
one thread in the future. It's too cumbersome to dynamically allocate a new single-threaded RM on request for each major
sub-resource in the directory tree.
|
|
|
Sean Boudreau(deleted)
|
Re: Unblock pulse with multithreaded RM
|
Sean Boudreau(deleted)
08/11/2009 9:19 AM
post35677
|
Re: Unblock pulse with multithreaded RM
On Tue, Aug 11, 2009 at 08:24:02AM -0400, Oleh Derevenko wrote:
> > >
> > > There has to be some synchronization at the rcvid level
> > > in the manager (locking of ocb etc) but that has to be
> > > there for other things other than the handling of unblock
> > > pulses. Then you can verify there's actually an unblock
> > > pending on the rcvid with MsgInfo() looking at the
> > > _NTO_MI_UNBLOCK_REQ flag in info.flags.
> >
> > I don't see how this can help. You can check if unblock is pending yet and
> > wait until pulse is handled if you find that. But you can't check if unblock
> > is going to appear in future. And since you can't make calls to MsgInfo and
> > following MsgReply to be atomic together you can't guarrantee that the unblock
> > pulse won't be received after you call MsgInfo() but before you call MsgReply
> > (). And if that happens we are back with original problem: how should unblock
> > pulse handler in thread B know that recvid recorded in OCB is indeed the
> > recvid it was intended for and not the next request that has been accepted by
> > thread A after original request had been successfully replied?
>
> So, do you confirm that unblock handler can't be reliably implemented if there is more than one thread in RM?
No. It should be able to architect your manager to handle
this issue. A rcvid in a manager maps to a particular
thread in a client. Said thread sends a message on a fd
which maps to an ocb in the server so the rcvid also
eventually maps to an ocb in the server. When the server's
unblock callout is called it can check if it's servicing the
rcvid in question on the passed ocb and if an unblock is
actually pending. If not it's either replied already or the
unblock callout arrived before the message callout. Both
cases should be able to be handled.
> You've got to do something with that - it's used everywhere.
> For me it's a great luck that I only used single-threaded RM's so far. But I need unblocking and I may need more than
one thread in the future. It's too cumbersome to dynamically allocate a new single-threaded RM on request for each major
sub-resource in the directory tree.
>
>
>
> _______________________________________________
>
> OSTech
> http://community.qnx.com/sf/go/post35663
>
|
|
|
Oleh Derevenko(deleted)
|
Re: Unblock pulse with multithreaded RM
|
Oleh Derevenko(deleted)
08/11/2009 9:42 AM
post35683
|
Re: Unblock pulse with multithreaded RM
> > So, do you confirm that unblock handler can't be reliably implemented if
> there is more than one thread in RM?
>
> No. It should be able to architect your manager to handle
> this issue. A rcvid in a manager maps to a particular
> thread in a client. Said thread sends a message on a fd
> which maps to an ocb in the server so the rcvid also
> eventually maps to an ocb in the server. When the server's
> unblock callout is called it can check if it's servicing the
> rcvid in question on the passed ocb and if an unblock is
> actually pending.
Since pulse is delivered asynchronously, even if you find that the ocb is servicing the recvid with matching value you
don't know if it's still your recvid or it is the next recvid with matching value assigned to it by coincidence.
As for checking MsgInfo... First, it looks to me that MsgInfo is somehow "thread-oriented" and should only be called
from the thread that had actually received that recvid. At least it stops returning the info as soon as the thread
returns to dispatch_block() even though the recvid itself has not been replied yet. That's why, if handler thread did
not save its struct _msg_info itself, you won't be able to access it later from unblock handler. And even if it saves
the info, it's of no use for this particular purpose as it might be outdated (saved before the unblock pulse receipt and
thust, not having the flag set).
> If not it's either replied already or the
> unblock callout arrived before the message callout. Both
> cases should be able to be handled.
Yes, all those cases could be handled if it would be possible to use MsgInfo from unblock callout.
|
|
|
Sean Boudreau(deleted)
|
Re: Unblock pulse with multithreaded RM
|
Sean Boudreau(deleted)
08/11/2009 11:30 AM
post35708
|
Re: Unblock pulse with multithreaded RM
On Tue, Aug 11, 2009 at 09:42:03AM -0400, Oleh Derevenko wrote:
> > > So, do you confirm that unblock handler can't be reliably implemented if
> > there is more than one thread in RM?
> >
> > No. It should be able to architect your manager to handle
> > this issue. A rcvid in a manager maps to a particular
> > thread in a client. Said thread sends a message on a fd
> > which maps to an ocb in the server so the rcvid also
> > eventually maps to an ocb in the server. When the server's
> > unblock callout is called it can check if it's servicing the
> > rcvid in question on the passed ocb and if an unblock is
> > actually pending.
>
> Since pulse is delivered asynchronously, even if you find that the ocb is servicing the recvid with matching value you
don't know if it's still your recvid or it is the next recvid with matching value assigned to it by coincidence.
> As for checking MsgInfo... First, it looks to me that MsgInfo is somehow "thread-oriented" and should only be called
from the thread that had actually received that recvid. At least it stops returning the info as soon as the thread
returns to dispatch_block() even though the recvid itself has not been replied yet. That's why, if handler thread did
not save its struct _msg_info itself, you won't be able to access it later from unblock handler. And even if it saves
the info, it's of no use for this particular purpose as it might be outdated (saved before the unblock pulse receipt and
thust, not having the flag set).
>
> > If not it's either replied already or the
> > unblock callout arrived before the message callout. Both
> > cases should be able to be handled.
>
> Yes, all those cases could be handled if it would be possible to use MsgInfo from unblock callout.
MsgInfo() has no such restriction AFAIK. It seems
to work in all threads in my experiments here.
Regards,
-seanb
|
|
|
Oleh Derevenko(deleted)
|
Re: Unblock pulse with multithreaded RM
|
Oleh Derevenko(deleted)
08/11/2009 11:37 AM
post35711
|
Re: Unblock pulse with multithreaded RM
> > As for checking MsgInfo... First, it looks to me that MsgInfo is somehow "
> thread-oriented" and should only be called from the thread that had actually
> received that recvid. At least it stops returning the info as soon as the
> thread returns to dispatch_block() even though the recvid itself has not been
> replied yet. That's why, if handler thread did not save its struct _msg_info
> itself, you won't be able to access it later from unblock handler. And even if
> it saves the info, it's of no use for this particular purpose as it might be
> outdated (saved before the unblock pulse receipt and thust, not having the
> flag set).
> >
> MsgInfo() has no such restriction AFAIK. It seems
> to work in all threads in my experiments here.
>
I did not check it right now but I clearly remember that MsgInfo returned error for me (not being able to find the
requested rcvid) when I tried calling it on asynchronous event from different thread after the RM thread has returned to
dispatch/handled few more requests.
|
|
|
Oleh Derevenko(deleted)
|
Re: Unblock pulse with multithreaded RM
|
Oleh Derevenko(deleted)
08/20/2009 12:58 PM
post36375
|
Re: Unblock pulse with multithreaded RM
> On Tue, Aug 11, 2009 at 08:24:02AM -0400, Oleh Derevenko wrote:
> > So, do you confirm that unblock handler can't be reliably implemented if
> there is more than one thread in RM?
>
> No. It should be able to architect your manager to handle
> this issue. A rcvid in a manager maps to a particular
> thread in a client. Said thread sends a message on a fd
> which maps to an ocb in the server so the rcvid also
> eventually maps to an ocb in the server. When the server's
> unblock callout is called it can check if it's servicing the
> rcvid in question on the passed ocb and if an unblock is
> actually pending. If not it's either replied already or the
> unblock callout arrived before the message callout. Both
> cases should be able to be handled.
OK, I try to check for (info.flags & _NTO_MI_UNBLOCK_REQ) before handling the request to make sure I've not missed an
unblock callout before the request itself. It's a single-threaded RM (actually, a multithreaded but they all are
serialized on a single mutex on entries to callouts).
Here is what I get (the logs are stripped from unnecessary info; best viewable with fixed width font)
4 15 09/08/20 19:36:10.082 CResourceManager::InternalRead rm.cpp:1119 CResourceManager:
:Read() (ocb=&085cd270, Path="prop/Mouse_Y.txt.cng", rcvid=4390954)
4 15 09/08/20 19:36:10.082 CDRMRequestData::ReadEx DataRequest.cpp:179 Blocked in cng
read
4 15 09/08/20 19:36:10.082 CResourceManager::InternalRead_PreProcessOCB rm.cpp:1267 Client has been
blocked (File="prop/Mouse_Y.txt.cng", ocb=&085cd270, Attr=&088f4868, Flow Suspended=false)
...
4 14 09/08/20 19:36:10.660 CResourceManager::InternalUnblock rm.cpp:1702 CResourceManager:
:InternalUnblock() (ocb=&085cd270, rcvid=4390954, Path="prop/Mouse_Y.txt.cng")
4 14 09/08/20 19:36:10.660 CResourceManager::UnblockAllActiveConnectionsForOCB rm.cpp:3239 Unblocking active
connection (Name="read", Index=0)
4 14 09/08/20 19:36:10.660 CResourceManager::DoReplyRead rm.cpp:1612 read() unblocked
...
4 14 09/08/20 19:36:10.662 CDRMRequestData::OnBlockEnd DataRequest.cpp:319 New data received
for file (Path="prop/Mouse_Y.txt.cng")
4 14 09/08/20 19:36:10.662 CDRMRequestData::OnBlockEnd DataRequest.cpp:340 Client is not
connected - store changes
...
4 17 09/08/20 19:36:10.662 CResourceManager::InternalCloseOCB rm.cpp:1484 CResourceManager:
:CloseOCB() (ocb=&085cd270, Path="prop/Mouse_Y.txt.cng")
4 17 09/08/20 19:36:10.662 - DataRequest.cpp:302 Unregistering
property notification
4 17 09/08/20 19:36:10.662 CResourceManager::InternalCloseOCB rm.cpp:1508 Closing file
(Path="prop/Mouse_Y.txt.cng", ocb=&085cd270, Attr=&088f4868)
...
4 18 09/08/20 19:36:11.648 CResourceManager::ProcessRequest_Open rm.cpp:2166 Open request has
been aborted immediately due to pending unblock request (Rcvid=4390954, Path="prop/Mouse_Y.txt.cng")
Here the file read request was blocked in RM. Then the unblock request has been received for it. The file read has been
aborted. Then the file has been closed by the client (close() callout does not check for _NTO_MI_UNBLOCK_REQ flag!!!).
And then, the following open() still detects the _NTO_MI_UNBLOCK_REQ flag set in msg_info and aborts immediately.
So, it's OK the rcvid can be reused. But is _NTO_MI_UNBLOCK_REQ state ever cleared from it?
I check for the flag like this:
int CResourceManager::CheckRequestImmediateAborters(resmgr_context_t *ctp)
{
int iResult;
do
{
int rcvid = ctp->rcvid;
if (rcvid != 0)
{
ASSERTE(rcvid != -1);
struct _msg_info info;
int iInfoResult =...
View Full Message
|
|
|
Oleh Derevenko(deleted)
|
Re: Unblock pulse with multithreaded RM
|
Oleh Derevenko(deleted)
08/21/2009 9:29 AM
post36411
|
Re: Unblock pulse with multithreaded RM
> Here the file read request was blocked in RM. Then the unblock request has been received for it. The file read has
been aborted. Then the file has been closed by the client (close() callout does not check for _NTO_MI_UNBLOCK_REQ flag!!
!). And then, the following open() still detects the _NTO_MI_UNBLOCK_REQ flag set in msg_info and aborts immediately.
>
> So, it's OK the rcvid can be reused. But is _NTO_MI_UNBLOCK_REQ state ever cleared from it?
Any commentaries for this case? If I remove the check for _NTO_MI_UNBLOCK_REQ before handling requests everything works
fine. And the code is quite old and well verified and the flag testing method I posted here should not bear any
suspicions, I suppose.
It's 6.3.9SP3 FYI.
|
|
|
Oleh Derevenko(deleted)
|
Re: Unblock pulse with multithreaded RM
|
Oleh Derevenko(deleted)
08/21/2009 3:17 PM
post36451
|
Re: Unblock pulse with multithreaded RM
> > Here the file read request was blocked in RM. Then the unblock request has
> been received for it. The file read has been aborted. Then the file has been
> closed by the client (close() callout does not check for _NTO_MI_UNBLOCK_REQ
> flag!!!). And then, the following open() still detects the _NTO_MI_UNBLOCK_REQ
> flag set in msg_info and aborts immediately.
> >
> > So, it's OK the rcvid can be reused. But is _NTO_MI_UNBLOCK_REQ state ever
> cleared from it?
>
> Any commentaries for this case? If I remove the check for _NTO_MI_UNBLOCK_REQ
> before handling requests everything works fine. And the code is quite old and
> well verified and the flag testing method I posted here should not bear any
> suspicions, I suppose.
>
> It's 6.3.9SP3 FYI.
With a quick glance at kernel sources it can be seen that _NTO_TF_UNBLOCK_REQ (and hence, _NTO_MI_UNBLOCK_REQ which is
derived from it) is maintained at per-thread base. In this case I can't understand at all how could the flag be used
with MsgInfo which operates with rcvid and which can be called from any thread (as you say it) if that flag is stored in
thread and not in rcvid-related structure.
|
|
|
Sean Boudreau(deleted)
|
Re: Unblock pulse with multithreaded RM
|
Sean Boudreau(deleted)
08/21/2009 4:56 PM
post36457
|
Re: Unblock pulse with multithreaded RM
On Fri, Aug 21, 2009 at 03:17:43PM -0400, Oleh Derevenko wrote:
> > > Here the file read request was blocked in RM. Then the unblock request has
> > been received for it. The file read has been aborted. Then the file has been
> > closed by the client (close() callout does not check for _NTO_MI_UNBLOCK_REQ
> > flag!!!). And then, the following open() still detects the _NTO_MI_UNBLOCK_REQ
> > flag set in msg_info and aborts immediately.
> > >
> > > So, it's OK the rcvid can be reused. But is _NTO_MI_UNBLOCK_REQ state ever
> > cleared from it?
> >
> > Any commentaries for this case? If I remove the check for _NTO_MI_UNBLOCK_REQ
> > before handling requests everything works fine. And the code is quite old and
> > well verified and the flag testing method I posted here should not bear any
> > suspicions, I suppose.
> >
> > It's 6.3.9SP3 FYI.
>
> With a quick glance at kernel sources it can be seen that _NTO_TF_UNBLOCK_REQ (and hence, _NTO_MI_UNBLOCK_REQ which is
derived from it) is maintained at per-thread base. In this case I can't understand at all how could the flag be used
with MsgInfo which operates with rcvid and which can be called from any thread (as you say it) if that flag is stored in
thread and not in rcvid-related structure.
In the kernel the rcvid is used to find the client thread.
-seanb
|
|
|
Oleh Derevenko(deleted)
|
Re: Unblock pulse with multithreaded RM
|
Oleh Derevenko(deleted)
08/21/2009 5:15 PM
post36460
|
Re: Unblock pulse with multithreaded RM
> >
> > With a quick glance at kernel sources it can be seen that
> _NTO_TF_UNBLOCK_REQ (and hence, _NTO_MI_UNBLOCK_REQ which is derived from it)
> is maintained at per-thread base. In this case I can't understand at all how
> could the flag be used with MsgInfo which operates with rcvid and which can be
> called from any thread (as you say it) if that flag is stored in thread and
> not in rcvid-related structure.
>
> In the kernel the rcvid is used to find the client thread.
Yes, that's great! But the availability of _RESMGR_NOREPLY status means that a thread can hold a rcvid while data
becomes available for it and meanwhile return to dispatch and handle few more requests. This way a single thread can
collect 2, 3, 5, - any number of rcvid's. And any subset of those rcvids can be requested for unblocking at the same
time with multiple pulses coming one right after another. How do you intend to keep unblock status for 3 rcvids's out of
5 if the thread only has a single flag for that?
|
|
|
Sean Boudreau(deleted)
|
Re: Unblock pulse with multithreaded RM
|
Sean Boudreau(deleted)
08/21/2009 5:47 PM
post36462
|
Re: Unblock pulse with multithreaded RM
On Fri, Aug 21, 2009 at 05:15:15PM -0400, Oleh Derevenko wrote:
> > >
> > > With a quick glance at kernel sources it can be seen that
> > _NTO_TF_UNBLOCK_REQ (and hence, _NTO_MI_UNBLOCK_REQ which is derived from it)
> > is maintained at per-thread base. In this case I can't understand at all how
> > could the flag be used with MsgInfo which operates with rcvid and which can be
> > called from any thread (as you say it) if that flag is stored in thread and
> > not in rcvid-related structure.
> >
> > In the kernel the rcvid is used to find the client thread.
>
> Yes, that's great! But the availability of _RESMGR_NOREPLY status means that a thread can hold a rcvid while data
becomes available for it and meanwhile return to dispatch and handle few more requests. This way a single thread can
collect 2, 3, 5, - any number of rcvid's. And any subset of those rcvids can be requested for unblocking at the same
time with multiple pulses coming one right after another. How do you intend to keep unblock status for 3 rcvids's out of
5 if the thread only has a single flag for that?
? When you do a MsgInfo the rcvid is used to
find the _client_ thread. The one and only
that maps to that rcvid in the server. Either
it's reply blocked on a channel in the server
with an unblock pending, or it's not.
-seanb
|
|
|
Oleh Derevenko(deleted)
|
Re: Unblock pulse with multithreaded RM
|
Oleh Derevenko(deleted)
08/22/2009 3:16 AM
post36467
|
Re: Unblock pulse with multithreaded RM
> ? When you do a MsgInfo the rcvid is used to
> find the _client_ thread. The one and only
> that maps to that rcvid in the server. Either
> it's reply blocked on a channel in the server
> with an unblock pending, or it's not.
>
So why after a read is unblocked the file is closed and re-opened once again - why do I get unblock flag pending
immediately on file open? I'm pretty sure the client thread does not request unblock as this is user input processing:
user presses a button - the file is open and reading starts, user releases the button - the read is unblocked and file
is closed. I know I did not release the button yet when open() is processed. Why do I get unblock pending flag on open()
immediately when I press button second, third and each next time?
The client thread might be the same but might be different each time - it's selected from pool and released back after
the reading is completed and file is closed.
|
|
|
Xiaodan Tang(deleted)
|
Re: Unblock pulse with multithreaded RM
|
Xiaodan Tang(deleted)
08/22/2009 9:40 AM
post36469
|
Re: Unblock pulse with multithreaded RM
> So why after a read is unblocked the file is closed and re-opened once again -
Why does this happened? Most likely you want to check the client code, what it will do if it's read() faild (you do fail
the read() when you try to handle the unblock request, right?)
> why do I get unblock flag pending immediately on file open? I'm pretty sure
> the client thread does not request unblock as this is user input processing:
> user presses a button - the file is open and reading starts, user releases the
> button - the read is unblocked and file is closed. I know I did not release
> the button yet when open() is processed. Why do I get unblock pending flag on
> open() immediately when I press button second, third and each next time?
> The client thread might be the same but might be different each time - it's
> selected from pool and released back after the reading is completed and file
> is closed.
I wouldn't so sure about "the client thread does not request unblock" part, maybe there is a timer keeps throwing
signals, maybe some other things casuing the unblock...
|
|
|
Oleh Derevenko(deleted)
|
Re: Unblock pulse with multithreaded RM
|
Oleh Derevenko(deleted)
08/22/2009 11:40 AM
post36470
|
Re: Unblock pulse with multithreaded RM
>
> I wouldn't so sure about "the client thread does not request unblock" part,
> maybe there is a timer keeps throwing signals, maybe some other things casuing
> the unblock...
>
No, that's totally impossible. I do not use timers at all. And unblocking is done by setting "aborted" flag in file
wrapper class, sending SIGINT signal to the thread and closing file descriptor right after that.
It means that even if I ignored the unblock pulse in the server and proceeded with open() I would still receive close()
with next request. But I don't! And even if close() would be handled before open() returns and would be ignored due to
the absence of file descriptor yet, the "aborted" flag would remain in file class forever and I would not be able to do
any reading from that file. But I am able to read it!
Well, the client thread after it returns from the request and notices that there was an attempt to unblock it, performs
pthread_kill(pthread_self(), 0) to handle SIGINT signal that might remain pending on it. Could not that pthread_kill()
leave _NTO_TF_UNBLOCK_REQ flag on the thread even though it is performed with zero signal? Well, I really-really doubt
that flag could survive those tons of code the thread executes through while it returns to the pool (having deleted all
the working objects) and comes back for next file open attempt (having created all the objects again).
|
|
|
Colin Burgess(deleted)
|
Re: Unblock pulse with multithreaded RM
|
Colin Burgess(deleted)
08/24/2009 10:09 AM
post36512
|
Re: Unblock pulse with multithreaded RM
Really you should capture the scenario in a kernel trace, that will tell you
exactly what is happening.
Oleh Derevenko wrote:
>> ? When you do a MsgInfo the rcvid is used to
>> find the _client_ thread. The one and only
>> that maps to that rcvid in the server. Either
>> it's reply blocked on a channel in the server
>> with an unblock pending, or it's not.
>>
>
> So why after a read is unblocked the file is closed and re-opened once again - why do I get unblock flag pending
immediately on file open? I'm pretty sure the client thread does not request unblock as this is user input processing:
user presses a button - the file is open and reading starts, user releases the button - the read is unblocked and file
is closed. I know I did not release the button yet when open() is processed. Why do I get unblock pending flag on open()
immediately when I press button second, third and each next time?
> The client thread might be the same but might be different each time - it's selected from pool and released back after
the reading is completed and file is closed.
>
>
>
> _______________________________________________
>
> OSTech
> http://community.qnx.com/sf/go/post36467
>
--
cburgess@qnx.com
|
|
|
Oleh Derevenko(deleted)
|
Re: Unblock pulse with multithreaded RM
|
Oleh Derevenko(deleted)
08/25/2009 8:34 AM
post36607
|
Re: Unblock pulse with multithreaded RM
I'm not ready to capture kernel traces yet (let's start with saying I never did that and I'm not sure how to do it).
However today I've discovered (I was suspecting this needs to be checked) that the problem could only be reproduced when
client and server are on different nodes. Locally everything works fine.
Also, it looks like the unblock flag is erroneously pending not for the open() only but for all the rest file operations
as well. This is not thoroughly verified yet but today I decided to disable unblock flag testing for open() (as open()
never blocks anyway) and leave it for all the rest file operations. However to my surprise, that did not solve anything
and file reading cycle still terminates. So it looks very likely that the subsequent read() that comes after the open()
also bails out due to unblock flag pending in msg_info on entry to callout.
> Really you should capture the scenario in a kernel trace, that will tell you
> exactly what is happening.
>
> > So why after a read is unblocked the file is closed and re-opened once again
> - why do I get unblock flag pending immediately on file open? I'm pretty sure
> the client thread does not request unblock as this is user input processing:
> user presses a button - the file is open and reading starts, user releases the
> button - the read is unblocked and file is closed. I know I did not release
> the button yet when open() is processed. Why do I get unblock pending flag on
> open() immediately when I press button second, third and each next time?
|
|
|
Oleh Derevenko(deleted)
|
Re: Unblock pulse with multithreaded RM
|
Oleh Derevenko(deleted)
08/26/2009 3:28 PM
post36742
|
Re: Unblock pulse with multithreaded RM
OK, I have set up an instrumented kernel with -vvv option, ran "tracelogger -b 640 -k 256 -r -w" and captured one
successful file open attempt and two or three failed attempts that followed it. You can find the trace log at the
following link <ask Colin Burgess for link>.
The rcvid with the unblock flag immediately pending was 196645.
If you need any other info, just let me know.
> Really you should capture the scenario in a kernel trace, that will tell you
> exactly what is happening.
>
> Oleh Derevenko wrote:
> >> ? When you do a MsgInfo the rcvid is used to
> >> find the _client_ thread. The one and only
> >> that maps to that rcvid in the server. Either
> >> it's reply blocked on a channel in the server
> >> with an unblock pending, or it's not.
> >>
> >
> > So why after a read is unblocked the file is closed and re-opened once again
> - why do I get unblock flag pending immediately on file open? I'm pretty sure
> the client thread does not request unblock as this is user input processing:
> user presses a button - the file is open and reading starts, user releases the
> button - the read is unblocked and file is closed. I know I did not release
> the button yet when open() is processed. Why do I get unblock pending flag on
> open() immediately when I press button second, third and each next time?
> > The client thread might be the same but might be different each time - it's
> selected from pool and released back after the reading is completed and file
> is closed.
> >
> >
> >
> > _______________________________________________
> >
> > OSTech
> > http://community.qnx.com/sf/go/post36467
> >
>
> --
> cburgess@qnx.com
|
|
|
|