[LV2] worker thread question
d at drobilla.net
Sun Dec 30 10:20:29 PST 2012
On Sun, 2012-12-30 at 19:07 +0100, hermann meyer wrote:
> Am 30.12.2012 18:09, schrieb David Robillard:
> > On Sun, 2012-12-30 at 17:39 +0100, hermann meyer wrote:
> > [...]
> >> Okay, have learn again a bit, hope I didn't forget it again to soon. :-)
> >> I have remove all threading stuff now, move the value check back into
> >> run, take a copy of my port values and call schedule->work() from run()
> >> to process my non rt work with the copy-ed values.
> >> here is the link to the current state:
> >> http://sourceforge.net/p/guitarix/git/ci/34a056c8838c36d384751d7c11c6fdc936e2e9a6/tree/trunk/src/LV2/gxamp.lv2/gxamp.cpp
> >> let me know case you see any violation in it any more.
> > Much better, though a pseudo-lock like schedule_wait here is
> > questionable. You can get situations where the update won't happen,
> > e.g. if the control changes to 3, work starts rebuilding, then changes
> > to 4 while that is happening, the 4 update will be skipped and things
> > will be set up incorrectly.
> Right, there was still one more mistake in it, thanks for pointing it out.
> I have change it now, so that the update check will check the port
> values again the last values which was used in the work queue
> (update_val() is called from the end of the work queue and set the
> compare value for the check, before schedule_wait is given free). As
> well I set it to block now in run(), before schedule->work is called. So
> if the port value change during work is running (or wait to running), it
> will run again as soon as possible on any value change.
That sounds sensible.
Queuing the requests instead would let you avoid the synchronisation and
just check against the last values *scheduled*, and avoid the need for
atomics, so it might be even simpler.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: This is a digitally signed message part
More information about the Devel