Remus
Sun Nov 30 22:17:49 CST 2003
I believe sys(2336) will not help you. If you re-enter a function and try to
aquire a critical section you still are in the same thread that already owns
it. So, you'll be granted the critical section (again), as the critical
section protects agains other threads, not against re-entry.
The simples approach is to set the AutoYield to .F. right at the function
entry and set it back to .T. before exit. Note that there still is a race
condition, if a the function is called second time right before the
AutoYield=.F. assignment. The chance of hitting it is quite low, so you
could first test if this actually is an issue that needs to be addressed or
is not.
HTH,
Remus
"Chip Orange" <acorange@worldnet.att.net> wrote in message
news:%23mKcwn6tDHA.1740@TK2MSFTNGP12.phx.gbl...
> Thanks so much for your reply.
>
> I did make a mistake in my original post, I do have autoyield set to .t.
My
> comments say that if it is set to .f., then the timer event won't fire if
> the user has a dialog active. I'm hoping my use of sys(2336) will take
care
> of the re-entrancy issues you mention.
>
> Chip
>
>
> "Remus" <nospam@nowhere.moon> wrote in message
> news:efAQ6%232tDHA.3536@tk2msftngp13.phx.gbl...
> > Igor is correct, VFP code is single threaded and all code runs in the
main
> > UI thread (the one that services the Windows message dispathing).
> > Also, the COM event of the ActiveX control is raised in the main thread
of
> > the host, since VFP offers only single threaded apartment model hosting.
> > When the ActiveX raises an event, a windows message is sent to a hidden
> > window and the main message pump of the app will dispatch this message,
> > eventually resulting in the event being 'raised'.
> > Setting .AutoYield to .T. makes the VFP code consume any pending windows
> > messages between each statement executed (using a while(PeekMessage())
> > loop). BTW, this is the same thing that DOEVENTS() is doing. That means
> that
> > if you let AutoYield to .T., your code should be reentrant. That is,
> > execution of any function/method/procedure can be intrerupted and the
> > function entered again (because of a new windows message). The original
> > execution will resume after the 'interrupting' execution is complete.
> > Personally, I much preffer to set AutoYield to .F. and issue DOEVENTS()
my
> > self if needed, e.g. in the middle of lengthy processing.
> >
> > HTH,
> > Remus
> >
> > "Chip Orange" <acorange@worldnet.att.net> wrote in message
> > news:OTsHV11tDHA.2308@TK2MSFTNGP11.phx.gbl...
> > > Thank you for your reply.
> > >
> > > For now, I have used sys(2336), as you suggest, around my
modifications
> of
> > > the shared data structures. I haven't designed a suitable test to see
> if
> > > this indeed is insuring exclusive access during these code fragments,
> but
> > so
> > > far no issues from adding this protection have turned up, and so far,
> the
> > > intermitant errors I was seeing from 2 or more code fragments
modifying
> > the
> > > shared COM object have gone away :) .
> > >
> > >
> > > I do believe, from the description of the activex control, that it is
> > > running in a separate OS thread in order to service the com port, and
> > > process and buffer the data, before it eventually calls my event
handler
> > > (which is passed a data buffer). My question is whether this event
> > handler
> > > is running as part of my VFP app's thread, or as part of the activex
> > > control's thread.
> > >
> > > Your description of all foxpro code being executed as one thread of
the
> > > interpreter sounds quite convincing, but still, with autoyield set to
> .F.
> > it
> > > *appears* to my code as if it is multi-threaded, and so I hope the
> > sys(2336)
> > > will take care of this. The documentation on exactly what this
function
> > > does isn't very clear or detailed.
> > >
> > > thanks again,
> > >
> > > Chip
> > >
> > > "Igor Korolyov" <k1i2v3@km.ru> wrote in message
> > > news:upKJW1wtDHA.3436@tk2msftngp13.phx.gbl...
> > > > Hi, Chip!
> > > > You wrote on Fri, 28 Nov 2003 15:51:09 -0500:
> > > >
> > > > CO> I have an app which has as one of its components an activex
> control
> > > > CO> which is constantly processing data from the serial port. I
need
> > the
> > > > CO> event handler for this code to be able to interrupt anything
else
> > I'm
> > > > CO> doing so that I don't lose any data.
> > > >
> > > > Hmm, what about internal buffers? I'd one day played with my analog
> > modem,
> > > > switching it to voice mode and accept digitized signal from it on
> 56700
> > > > Kbit/s speed without any troubles - using MSCOMM ActiveX control.
> > > >
> > > > CO> I also have a timer which I need to run once a second and do
some
> > > > CO> processing of the data.
> > > >
> > > > CO> I also of course have a form with which the user can interact.
> > > >
> > > > CO> Because of the serial port handler, I have the application
> > autoyield
> > > > CO> property set to .f.
> > > >
> > > > That's OK.
> > > >
> > > > CO> My problem arises from the unfortunate need for all three of
> these
> > > > CO> "threads" to access some of the same data structures and
objects.
> > > >
> > > > AFAIK they are not real "threads" in the CPU point of view... They
are
> > > just
> > > > different pieces of VFP code, that are executed sequentially by
> > > interpreter
> > > > (VFP executive subsystem)... There is really some tools to create
> > > > multithreaded VFP apps, but if you don't know for sure that your
code
> > _is_
> > > > multithreaded - then it is really not :)
> > > >
> > > > CO> I'm wondering if I can use some of the
> > > > CO> Windows control structures such as critical sections mutexes or
> > > > CO> semaphores to handle this? In trying to read about them, it
> seems
> > > > CO> important that the various items which are competing for the
> > resource
> > > > CO> be either in different threads or different processes (or the
> > > > CO> WaitForSingleObject() function won't wait).
> > > >
> > > > You really CAN, but IMHO it won't work, as it will be called from
one
> > > > thread...
> > > >
> > > > CO> Can someone tell me if these components are running in
different
> > > > CO> threads, and then could someone recommend which of these
Windows
> > > > CO> features might be best suited to allowing short exclusive use
of
> > > > CO> resources?
> > > >
> > > > AFAIK ALL _user_ code (timer event handlers, ActiveX event handlers,
> > Form
> > > > event handlers, methods and all the rest) is executed in one thread,
> > only
> > > > system code is executed in separate threads, but they definetely
don't
> > use
> > > > your data structures, what they can do - switch to one or another
part
> > of
> > > > your user code... But if you really have COM component (maybe
> > > > multithreaded), that will interact (from within it's internal C/C++
> > code)
> > > > with your data structures via VFPAPI calls then you may need all the
> > > > syncronization stuff...
> > > > Some of them are even moved "closer to user" in recent VFP
versions -
> > say
> > > > SYS(2336) that is Enter/LeaveCriticalSession wrapper.
> > > >
> > > > --
> > > > WBR, Igor
> > > >
> > > >
> > >
> > >
> >
> >
>
>