Threads & sync event tiggered prematurely - Daniel? Someone?
Mike C
I see Daniel Lohmann is up on threads and since threads are a kernel thing,
I'll try this question again. (I hope the syncronization stuff isn't
off-topic, cause this
is about events now that I think of it.)
I had this problem in win95 and someone else e-mailed me with the same thing
that
suddenly cropped up with his NT program. The OS I was developing on was a
fresh install.
We didn't find an answer in the other groups.
Seems that if I created a class member function to call CreateEvent( ) on a
number of event handles
and called WaitFor....Object(s)( ) - whichever - later, the Wait would
return immediately
with a return code indicating the wait event was satisfied. In the interrupt
handler ( the ISR
in question was user-mode code written on top of WinDriver kernel-mode b.s.)
I set the event and set a flag. Even though the wait returned, the flag was
never set, indicating
that the interrupt never occured.
The real pisser is that if I do this:
HANDLE hFIFOAlmostFullEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
at file scope and leave the CreateEvent stuff out of my pci card driver
class,
it works. The wait doesn't return 'til the event is set in the ISR and the
verification is
the fact that the extra flag I stuck in there for debugging is set. No
premature behavior.
The flag gets reset at the beginning of the ISR, the event gets set, then
the flag is set.
Is this freakin' weird?
Now we have to release the handles somewhere in another source file or way
down in the class
destructor.
Here's the meta-program:
#include <caffeine_and_prozac.megadose>
// ****** IF YOU ALLOCATE RESOURCES HERE YOU'LL NEED TO
// ****** CLEAN UP YOUR MESS IN ANOTHER FILE - JUST A REMINDER
// ****** FROM THE SORRY GUY WHO WROTE THIS BLASTED PROGRAM
:-)
Any help on this would be greatly appreciated. I don't want this to happen
next time and
I like the encapsulation method since then I don't have to allocate
resources for the event
( there were a bunch ) until I need them.
Thanks in advance,
mike
Daniel Lohmann
>Hi:
>
>I see Daniel Lohmann is up on threads and since threads are a kernel thing,
>I'll try this question again. (I hope the syncronization stuff isn't
>off-topic, cause this
>is about events now that I think of it.)
>[...]
Thanks a lot for all those flowers, Mike :-)
But hope they were not that expensive. Aactually I don't think that I
can help you :-(((
To be honest, I have no experiences in writing device drivers and
sharing kernel objects between kernel mode and user mode. I suppose
your problem has something to do with where you create the event (km
or um), but I'm not sure that I really understood what you want to
tell us...
Daniel
Mike C
this works:
#include whatever
HANDLE hFIFOAlmostFullEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
class XCVR
{
// encapsulation of 3rd party API and the code to make it work.
// API is jungo.com's WinDriver P9080 API for the PLX 9080 pci inyerface
:-) chip
// API implementation is straight c (!!) and calls jungo's WinDriver
(WD_xxx) functions
// which are the only kernel mode functions.
// P9080_xxx functions needed tweaks -- $1500 -- at least it saved SOME
time.
};
int DMA(DWORD* block, blah, blah)
{
// do stuff
WaitForSingleObject(hFIFOAlmostFullEvent, ...);
// do more stuff
return 0;
}
int ISR( )
{
flag = 0;
// check PCI interface chip registers for int flags and apply mask
SetEvent(hFIFOAlmostFullEvent);
flag = 1; // to double check reason for interrupt
// do whatever
return 0;
}
this does not work:
HANDLE hFIFOAlmostFullEvent;
class XCVR
{
public:
int AllocateResources()
{
hFIFOAlmostFullEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
return 1;
}
};
int DMA(DWORD* block blah, blah)
{
// do stuff
WaitForSingleObject(hFIFOAlmostFullEvent, ...); // returns immediately
with wait satisfied (not time out) .
// condition and flag (below) will be set.
// do more stuff
return 0;
}
int ISR( )
{
flag = 0;
// check PCI interface chip registers for int flags and apply mask
SetEvent(hFIFOAlmostFullEvent);
flag = 1; // to double check reason for interrupt
// do whatever
return 0;
}
all this is happening in user mode. - same .cpp file. - it doesn't make
sense.
flowers, Daniel? i guess you mean the implied compliment, not the attempted
humor?
not sure if I understand the figure of speech though it rings a bell. it's
rare.
my only expense is trying to explain the problem. the rest was easy. hmm...
i'm not trying to tell, i'm trying to fix. or find out what could cause this
so that i don't have to
repeat the first frag. i like the second implementation. i've done it before
and it works - across
multiple files and across threads. the tech director of the project insisted
on
winders 95, so that could be the prob, though it shouldn't be a prob at all.
it's too weird.
thanks in advance,
mike
Daniel Lohmann <dan...@uni-koblenz.de> wrote in message
news:jsnu7tc0pl55s485d...@4ax.com...
Daniel Lohmann
[...]
>
>this does not work:
>
>HANDLE hFIFOAlmostFullEvent;
>
>class XCVR
>{
> public:
> int AllocateResources()
> {
> hFIFOAlmostFullEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
> return 1;
> }
>};
>
>int DMA(DWORD* block blah, blah)
>{
> // do stuff
> WaitForSingleObject(hFIFOAlmostFullEvent, ...); // returns immediately
>with wait satisfied (not time out) .
What is the returncode of GetLastError() at this point?
"not timed out" is not the same as "WAIT_OBJECT_0", since the result
can also be "WAIT_FAILED", in which case GetLastError() returns the
reason.
>// condition and flag (below) will be set.
> // do more stuff
>return 0;
>}
>
Your problem looks to be an initialization problem.
I suppose the returncode of GetLastError() would be
"ERROR_INVALID_HANDLE" (0x6).
Daniel
Mike C
> What is the returncode of GetLastError() at this point?
> "not timed out" is not the same as "WAIT_OBJECT_0", since the result
> can also be "WAIT_FAILED", in which case GetLastError() returns the
> reason.
Thanks. Sorry. Been away. There's no way for me to tell at this point.
The company
I wrote the app for ran out of money and I have a $7600 judgement
against them.
If I run the app on my system, it will not work because I don't have
a PLX9080
PCI Interface chip on any of my PCI cards. Even then, the ap is for a
General
Standards PCDI32 card.
If this is the only possible way to find out what's up, and this is
the only possible
cause of the problem, I'll try that next time. Seems to me that I did
the same
thing in my app that reads the sound card as I did with the PCI driver
code.
That is, I encapsulated the synchronization code in a class. Of
course, that was an Event
class and in the case of the problem app, CreateEvent is in a member
function of
the driver class. Shouldn't matter.
If WAIT_OBJECT_0 means that the wait was satisfied by a signaled
event,
then that is what I meant by "not timed out" and that is what I got
for a return
in the problem app.
I'm looking for clues to the cause of this problem in case it comes up
again.
GetLastError has some times returned stupid messages like "the
operation
completed normally." This may be due to calling GetLastError after
the real error was cleared be a successful operation.
So unless there's some other reason that this would occur, I'll just
have to
wait until it happens again.
> Your problem looks to be an initialization problem.
> I suppose the returncode of GetLastError() would be
> "ERROR_INVALID_HANDLE" (0x6).
I wonder why I'd have an invalid handle. The handle is declared
at file scope and is therefore visible to the member function where
CreatEvent assigns the handle to it. Then the handle is used in
another
member function which can see the declaration - but of course,
otherwise it
wouldn't compile.
If your out of ideas we may as well wait until then. At least I got
some help
this time around. When I was working on the app at DART, all I got was
another dude with the same prob. So thanks for giving it a shot,
Daniel.
Sorry I can't do any trouble shooting on it. We may have found the
problem.
As for DART, I have the source, they have zip, and my app wouldn't
help
them if they had it 'cause YOU CAN'T SEND 20 Mbps OVER THE PSTN
ANYWAY, FRED. The psuedo-scientist will probably die thinking it
really worked
for him and the engineers just didn't properly design the circuits
that he can't design.
Thanks again. I'll check back to see if you have any furthur thoughts.
Mike