[lldb-dev] Locking issues

[Malea, Daniel]

Ah, sorry on re-read, I realize I should have written "inferior" instead
of "process" in that paragraph. The private/public state thing makes
perfect sense, and I don't think would need to be changed. Private state
should not leak out, and might vary many times during the "non-const" /
"long-running" operation we're talking about, SB users would only see
public state before and after one of these operations long operations.


TL;DR: I'm not sure that a second R/W lock is the right synchronization
primitive to use for the internal lock. I think a condition variable in
tandem with the first lock is what we are looking for.



Cheerio,
Dan

On 2013-04-18 10:38 PM, "Jim Ingham" <jingham at apple.com> wrote:

>I'm heading out now so I didn't read this in detail, I'll do so tomorrow,
>but I just want to clarify this one point.
>
>It is not true that processes have one state.  They have two, a public
>state, and a private state.  When you do a user level "step-over" for
>instance, you are actually single-stepping the process multiple times get
>through the range (plus stepping in, running back out again, calling
>functions to figure out how to step through trampolines, etc...)  So for
>many cases where to the outside world the process looks like it has just
>"been running" it has in fact stopped and started many times.
>
>It is important that these private state changes not leak out to people
>who are waiting on state changed events at the Process level.  The whole
>logic of the execution control depends on this distinction being
>carefully maintained.
>
>That's why the notion of a "private run lock" and a "public run lock"
>seemed like a reasonable solution, since they mirror this basic construct
>within lldb's execution engine.
>
>Jim
>
>On Apr 18, 2013, at 7:17 PM, "Malea, Daniel" <daniel.malea at intel.com>
>wrote:
>
>> Sorry I was not too clear -- basically I'm worried about the complexity
>>of
>> having two discrete R/W locks here, and separate behaviour based on
>> internal/external threads. Since processes have one state, it "feels"
>>like
>> there should be one lock.
>> 
>