groovy

@Bindable/@Vetoable should generate getter/setters that assert proper multi-threaded access

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.8.1, 1.9-beta-1
  • Fix Version/s: None
  • Component/s: Swing
  • Labels:
    None
  • Number of attachments :
    0

Description

A proposal is to add synchronized to the method signatures.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Dierk Koenig added a comment -

The point here is that when using Bindable in a multi-threaded context, we must make sure to have proper read-write guards, either by making field access volatile or by using synchronization.

Other means like gpars agents could also be an option but may be to heavy of a tool for such a simple purpose.

A multi-threaded context e.g. appears when using Bindable with presentation models that are accessed outside the EDT but the binding updates visual (swing) controls inside the EDT.

Show
Dierk Koenig added a comment - The point here is that when using Bindable in a multi-threaded context, we must make sure to have proper read-write guards, either by making field access volatile or by using synchronization. Other means like gpars agents could also be an option but may be to heavy of a tool for such a simple purpose. A multi-threaded context e.g. appears when using Bindable with presentation models that are accessed outside the EDT but the binding updates visual (swing) controls inside the EDT.
Hide
Permalink
blackdrag blackdrag added a comment -

Let us assume Thread T1 writes and the EDT will read the values. If you do a per property synchronization, then the EDT will see the new value if it reads after T1 has written. The point now is, if the EDT waits for a read and T1 wants to write more than 1 property, a per property synchronization may mean, that the EDT will see the new value of the first, but an old value for the second property.

If we assume T1 and EDT write, then it can become quite random what value will be visible in the end.

Show
blackdrag blackdrag added a comment - Let us assume Thread T1 writes and the EDT will read the values. If you do a per property synchronization, then the EDT will see the new value if it reads after T1 has written. The point now is, if the EDT waits for a read and T1 wants to write more than 1 property, a per property synchronization may mean, that the EDT will see the new value of the first, but an old value for the second property. If we assume T1 and EDT write, then it can become quite random what value will be visible in the end.

People

  • Assignee:
    Andres Almiray
    Reporter:
    Andres Almiray
Vote (1)
Watch (0)

Dates

  • Created:
    Updated: