Incorrect locking for record-type attributes
Bug #1577761 reported by
mdavidsaver
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| EPICS Base |
Confirmed
|
Low
|
Unassigned | ||
Bug Description
From lp:1577108
Andrew Johnson says:
> On examination of this code I see that attributes are a pin-hole in our
> record locking scheme, given that they store a per-record-type value,
> not per-record-
> would get set at startup and never changed afterwards, but we don't have
> anything in the code to enforce that. I know that I-Tech use them in
> their Libera IOCs but I don't know if they ever change their values at
> runtime. However since the "field" address doesn't change even when you
> change the value and they store a fixed-length string, I don't see this
> as a big problem, at worst a client would get a mixture of old and new
> string values.
Revision history for this message
| mdavidsaver (mdavidsaver) wrote | #1 |
To post a comment you must log in.
In thinking about this, I imagine using a "fake" record instance (and associated lock set) for each recordtype. "fake" in that it would not be in the record list or hash, and thus not reachable by the normal means. This would allow record type attributes to have a complete dbAddr/dbChannel struct.