Hello Till,
On 02/07/2011 08:05 AM, Sebastian Till wrote:
> I have a problem with my multithreaded application (with OpenSG 1.8). To
> illustrate what my program does I added some simplified samples of my
> original code (e.g. access to the boolean variables is done via
> InterlockedExchange calls within the original code).
> The main thread pushes information (e.g. a filename) about geometry that
> needs to be loaded into the background thread. The background thread in turn
> will use this information to finally load the geometry. The synchronisation
> part is the tricky one. Pushing filenames into the background thread needs to
> be done in a thread safe manner. I do that by entering a critical section,
> pushing as much information as needed to the background thread and then
> leaving the critical section. After that the methods BackgroundThread::synch
> and BackgroundThread::applyChanges are called by the background thread and
> the main thread, respectively.
>
> The call that entered the critical section I mentioned above also sets a flag
> mAppChangesNeeded to true. The method BackgroundThread::synch() will apply
> the changes made by the background thread to the main thread and if the
> mAppChangesNeeded flag is equal to true the bg thread will also receive
> changes made by the main thread.
> However, here is where my problem occurs. Sometimes the background thread
> wants to receive changes because the mAppChangesNeeded flag is true but the
> main thread will never reach the corresponding code within
> BackgroundThread::applyChanges because it already left this method. Leading
> to a background thread captured within a call for gSyncBarrier->enter(2).
I think the scenario that leads to this deadlock goes something like
this (MT = main thread, BT = background thread):
MT goes into applyChanges()
BT goes into synch()
both go through the two initial barriers, after the second one MT is
scheduled first.
MT calls beginAlteration(), endAlteration()
context switch to BT, with mAppChangesNeeded == true now.
BT gets stuck on the third barrier in synch.
> I have no idea why this can happen. Maybe some of you can see my mistake by
> looking at the code below. I hope I didn't confuse you with my explanations.
> Any hint is appreciated and if you think that there's a better of way a
> accomplishing my goal, please, let me know.
I think the solution would be to make synch atomic wrt to
begin/endAlteration(), perhaps by having sync() enter/leave the same
critical section.
Cheers,
Carsten
------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
