Re: Unexpected reentrancy on Wait,etc...

I suppose the non-reentrant code could be moved into a new thread with
a queue. This doesn't solve the general problem that the GUI can
reenter anytime it locks and it is very difficult to guarantee the
rest of the GUI code is reentrant. Re your second point. The code is
currently guarded and throws an exception indicating the caller
violated the transaction discipline. Failure is not an option because
the receiver could be a customer calling thru the API.

Thanks for your suggestions,

Jake

On Nov 5, 3:31 pm, "Frank Hileman"
<frank...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hi Jake,

Usually some code using locks can be reworked such that each thread works
with private copies of data only, returning data using a centralized queue,
with only the centralized queue being thread safe (using locks or other
techniques).

If you don't mind your reentrant function failing, set a boolean field to
true on entry of the function, and set it to false in a finally statement at
the end of the function (the body being in a try). Then add a check to the
top of the function to bail out if you are already executing the function.
That is the standard non-reentrancy guard.

Regards,
Frank Hileman

check out VG.net:http://www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio graphics editor

"jaket" <jtumm...@xxxxxxxxx> wrote in message

news:1194046798.871695.228490@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



Hello,

I have run into a serious reentrancy problem. It appears from a stack
trace that lock, WaitOne and Thread.Join do some servicing of the
message queue. Here is the setup:

The GUI thread uses a combination of Application.Idle and a timer to
simulate the old MFC OnIdle. The Idle handling will periodically pick
up some work that requires executing some non-reentrant code. This
code uses several locks to synchronize with other threads.

Another background worker thread is calling thru the Application's
API. The API must use Control.Invoke using the MainForm to marshal
the calls to the GUI thread. It also calls the non-reentrant code.

While GUI thread is waiting on a lock (I presume that it is already
held by a 3rd thread), the Control.Invoke can occassionaly slip thru
and cause reentrancy. Anyone familiar with the perils of DoEvents
will understand why this is a major problem.

Any suggestions?

Sincerely, Jake- Hide quoted text -

- Show quoted text -


.

Relevant Pages

  • Re: Unexpected reentrancy on Wait,etc...
    ... OnIdle is used to purposely slow updates to the GUI. ... The locks are not held by either thread for long. ... thread's message queue. ...
    (microsoft.public.dotnet.framework.clr)
  • [PATCH] remove lame schedule in journal inverted_lock (was: Re: [patch 0/3] j_state_lock, j_list_loc
    ... patch is appropriate. ... > Hi Andrew, ... Making those two locks global causes this deadlock on kjournal ... * state wait queue and we'll be woken up when it is unlocked. ...
    (Linux-Kernel)
  • Re: 6.0-BETA2: taskqueue_drain for if_xl.c:2796
    ... On Tuesday 16 August 2005 01:21 pm, John Baldwin wrote: ... >> drop locks in order to be sure that a mess isn't created. ... case that the task is sitting in the queue, but the code will work fine ... or don't think the optimization is worth it, ...
    (freebsd-current)
  • Re: 6.0-BETA2: taskqueue_drain for if_xl.c:2796
    ... >>being able to cancel a taskqueue without having to worry about locks, ... > here for both callout and taskqueue are to make sure that if the other thread ... > waits on it to finish if it is either in the queue or running. ... locks held is a convenience doesn't hold water. ...
    (freebsd-current)
  • Re: moving data from one place to another in a text file
    ... >> each word is pulled only once from the queue. ... only locks required are on the last card in each pile. ... >for example, that multi-threading will save resources, but it does this ... ASSumptions about other processes at design time is the path to ...
    (comp.lang.cobol)