[LV2] worker thread question

[hermann meyer]

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.

>
> I suppose you are trying to avoid doing "too many" updates, but anything
> other than simply scheduling work, and executing work, won't work quite
> correctly in some cases.  The idea of the worker is to avoid such
> problems with a simple queue mechanism.  A better solution would be to
> push the values you need to the worker rather than push a useless bool
> and cache values in the plugin and depend on sync.  Think of the worker
> as a queue of work items, not a thread API.  This way you have a
> graceful pipeline of work to execute with no synchronization issues at
> all.  In general, you want to push all the information you need through
> the queue, not cache it in the instance, since several requests can be
> scheduled at one time.
>
> In this case you would push something like
>
> struct WorkRequest {
>      float alevel;
>      float clevel;
> };
>
> through the worker queue.
>
> That said, this code is much better and shouldn't cause any serious
> problems.
>
> A better solution to the 'too many rebuilds' problem would be to cache
> the most recent values somewhere but only send a work update at most
> every n frames for some reasonable value of n.  That said I would start
> with the simple/normal work queue and worry about that later *if* you
> need to.  It's quite possible it will work fine.

I will think about that as well,
> Premature optimization is the root of all evil ;)
>
> -dr
>
and this as well :-)


thanks
hermann