[LV2] worker thread question

[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.

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.

Premature optimization is the root of all evil ;)

-dr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20121230/fb0bcaee/attachment-0002.pgp>