Qt-interest Archive, July 2007
Dll Access - Speed with Qt vs. Win32 API
Message 1 in thread
Dear all,
I have a strange problem while accessing a dll to control a machine. At the
moment I use the QLibrary function resolve to resolve the functions of the
dll.
Now when I try to call the dll functions it happens from time to time that a
call gets lost and the function is not executed. Especially when I call some
status functions every 5ms or so.
A long time ago I implemented something similar but with direct Win32 API
functions like GetProcAdress and so on to resolve the function names of the
dll and I can not remember the same problems like lost calls and so on.
Can it be that Qt is just not fast enough or has such a great overhead that
as a result I get the problems I have at the moment?
Thank you for your contributions in advance.
Joachim
Message 2 in thread
Joachim Zettler wrote:
> Now when I try to call the dll functions it happens from time to time
> that a
> call gets lost and the function is not executed. Especially when I call
> some
> status functions every 5ms or so.
Is there any multi-threading involved in your program? Static variables
or globals that could be getting clobbered so you lose track of the call?
> Can it be that Qt is just not fast enough or has such a great overhead that
> as a result I get the problems I have at the moment?
That seems exceedingly unlikely. Also, have a look at the implementation
of QLibrary, in particular src\corelib\plugin\qlibrary_win.cpp . You
will see that QLibrary is really just providing a wrapper around the
underlying win32 calls (with different wrappers provided on other
platforms).
--
[ signature omitted ]
Message 3 in thread
> Joachim Zettler wrote:
>
>> Now when I try to call the dll functions it happens from time to time
>> that a
>> call gets lost and the function is not executed. Especially when I call
>> some
>> status functions every 5ms or so.
>
> Is there any multi-threading involved in your program? Static variables
> or globals that could be getting clobbered so you lose track of the call?
Also, what mechanism are you using to trigger the 5ms timer calls? Is
the time source and implementation that uses it capable of reliably
triggering with that sort of frequency? Time sources vary in resolution
and there can be problems with using timers to trigger very frequent events.
--
[ signature omitted ]
Message 4 in thread
Hi Craig,
thank you for your suggestions. In fact I use a QTimer to call a slot where
a dll function is executed.
I have several threads in my program and they all share the access to the
globally defined dll instance.
For example: One of the threads is calling a Status function of the dll
every 5ms and is writing the current status in a member struct inside that
thread.
Another thread is performing the machine movement and is therefore calling
some move functions from the dll. Now from time to time it happens that a
call to a move function is just not working and the machine is just doing
nothing.
If it has nothing to do with the qt speed because qt simply wraps around
win32 api then it might be that two threads try to call the dll at the same
time and then there might be a problem :(
Or what do you think?
Take care.
Joachim
2007/7/8, Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx>:
>
> > Joachim Zettler wrote:
> >
> >> Now when I try to call the dll functions it happens from time to time
> >> that a
> >> call gets lost and the function is not executed. Especially when I call
> >> some
> >> status functions every 5ms or so.
> >
> > Is there any multi-threading involved in your program? Static variables
> > or globals that could be getting clobbered so you lose track of the
> call?
>
> Also, what mechanism are you using to trigger the 5ms timer calls? Is
> the time source and implementation that uses it capable of reliably
> triggering with that sort of frequency? Time sources vary in resolution
> and there can be problems with using timers to trigger very frequent
> events.
>
> --
> Craig Ringer
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
Message 5 in thread
Joachim Zettler wrote:
> For example: One of the threads is calling a Status function of the dll
> every 5ms and is writing the current status in a member struct inside that
> thread.
I hope your access to any shared data structures is very carefully
locked or otherwise checked to ensure proper mutual exclusion. (If it's
not, well, Qt provides some reasonably easy to use classes to help with
this).
> Or what do you think?
I suspect you have a bug with your threading - possibly caused by
incorrect/missing mutual exclusion at some point, such as a
callback/slot that processes timer events. So you might be executing the
missing timer handlers, but overwriting their results.
Alternately, you might just be relying on too high an available timer
resolution, so timers simply aren't always being triggered when you ask
for them. I don't know how various OSes handle missed timer events
(whether they queue them, discard them, etc) and for all I know this
might be part of the problem. I'd be very surprised if 5ms wasn't OK
with some kind of high-res timer - but I wouldn't bet on it working for
general purpose timers especially under high system load. AFAIK
different platforms have all sorts of different exciting limits on high
res time sources so that's probably something you'll want to look into.
Check out QEventDispatcherWin32::registerTimer(...) from
qeventdispatcher_win.cpp for how Qt implements timers on win32. You
might want to see what kind of timer Qt is acquiring, since on win32 it
seems to try to get high-resolution multimedia timers first.
This article:
http://www.opcware.com/XtraTimer/MultimediaTimers.html
discusses win32 timer types, resolution issues, message queue
priorities, etc. It's just a semi-random one off Google that looks
interesting. Yes, that is a hint.
Hope you have some success tracking this down.
--
[ signature omitted ]
Message 6 in thread
Hi Craig,
currently I use a Mutex to protect the shared struct or variables. But I
think I found out what might be the problem.
The dll is not really thread safe. I asked the vendor for support and they
told me that thread-safe will be included in a future release but is not
implemented yet :(
So I need to change my program in order to allow only one thread to access
the dll :(
But thanks a lot for the link to the article...this is really something very
interesting for me.
Take care.
Joachim
2007/7/8, Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx>:
>
> Joachim Zettler wrote:
>
> > For example: One of the threads is calling a Status function of the dll
> > every 5ms and is writing the current status in a member struct inside
> that
> > thread.
>
> I hope your access to any shared data structures is very carefully
> locked or otherwise checked to ensure proper mutual exclusion. (If it's
> not, well, Qt provides some reasonably easy to use classes to help with
> this).
>
> > Or what do you think?
>
> I suspect you have a bug with your threading - possibly caused by
> incorrect/missing mutual exclusion at some point, such as a
> callback/slot that processes timer events. So you might be executing the
> missing timer handlers, but overwriting their results.
>
> Alternately, you might just be relying on too high an available timer
> resolution, so timers simply aren't always being triggered when you ask
> for them. I don't know how various OSes handle missed timer events
> (whether they queue them, discard them, etc) and for all I know this
> might be part of the problem. I'd be very surprised if 5ms wasn't OK
> with some kind of high-res timer - but I wouldn't bet on it working for
> general purpose timers especially under high system load. AFAIK
> different platforms have all sorts of different exciting limits on high
> res time sources so that's probably something you'll want to look into.
>
> Check out QEventDispatcherWin32::registerTimer(...) from
> qeventdispatcher_win.cpp for how Qt implements timers on win32. You
> might want to see what kind of timer Qt is acquiring, since on win32 it
> seems to try to get high-resolution multimedia timers first.
>
> This article:
> http://www.opcware.com/XtraTimer/MultimediaTimers.html
> discusses win32 timer types, resolution issues, message queue
> priorities, etc. It's just a semi-random one off Google that looks
> interesting. Yes, that is a hint.
>
> Hope you have some success tracking this down.
>
> --
> Craig Ringer
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
