|Subject:||Re: [Discuss-gnuradio] Regarding lock protection when setting private variables in gnuradio blocks|
|Date:||Thu, 16 Oct 2014 12:59:44 -0400|
Yeah, so, a little cerebral flatulence on my part.
I think the problems come in with variables that can "change shape" during a setting operation, which could lead
to horrific badness if the "shape change" happens while the work function is using the variable. Imagine a
private buffer whose size and, potentially, base-address, can change during the work function.
The scalars are "safer", but not completely "safe", in that they could have semantics with bad consequences if
they change during work function processing. Those bad consequences can be either rather benign--for example
a gain changing during processing of samples--just leads to a glitch, or much-worse, core-dumping territory.
On 2014-10-16 11:32, Johnathan Corgan wrote:
On 10/16/2014 07:54 AM, address@hidden wrote:Is it not the case that a given instance of a block is only ever executed by a single thread, so instance variables are completely safe to modify in-flight?There is one thread that alternates calling the async message handlers, the forecast function, and the work function, so variables shared only by these three do not need protection. However, public functions on a block are called from another thread context (which ever thread the user calls them from), and are completely asynchronous to the block's runtime thread. Many public block functions in GNU Radio are not thread-safe because of this, but in practice work fine as Tom explained. Now that we've had the ability to use asynchronous messaging between blocks or from outside GNU Radio into a block for quite some time, I would encourage block developers to take advantage of their thread-safe nature and think about how to use them to update the operations of their blocks vs. calling public functions.
|[Prev in Thread]||Current Thread||[Next in Thread]|