Attributes synchronized
4 views
Skip to first unread message
Miguel Branco
Apr 8, 2021, 4:07:24 AM4/8/21
to kiama
Hi all,
As part of moving from Kiama 2.1.0 to a newer version, we've been looking at recent changes.
When first trying the migration, we noticed a deadlock. This was now visible as attributes became synchronized. Probably had been harmless thus far in our specific scenario, but a good catch nonetheless.
Looking at the implementation quickly, I see that the synchronization is happening at the value T. Shouldn't this be happening per combination of attribute and value? Can't we have a case where two separate attributes lock on a value while trying to obtain the other one?
Cheers,
Miguel
Tony Sloane
Apr 19, 2021, 8:46:06 PM4/19/21
to Kiama
Hi Miguel,
Sorry for my delay in responding.
I think we ended up with just synchronising on the value to keep things simple. And it worked for the use case that another user had.
I’m not sure what you mean by "two separate attributes lock on a value while trying to obtain the other one”. I would expect normal (non-circular) attributes to not be dependent in a cycle, so such a deadlock shouldn’t happen. I.e., if a and b are normal attributes, T.a depends on T.b, and vice versa, then the attribute grammar is not well-defined. Do you have a use-case where this kind of dependence is desired?
cheers,
Tony
Sorry for my delay in responding.
I’m not sure what you mean by "two separate attributes lock on a value while trying to obtain the other one”. I would expect normal (non-circular) attributes to not be dependent in a cycle, so such a deadlock shouldn’t happen. I.e., if a and b are normal attributes, T.a depends on T.b, and vice versa, then the attribute grammar is not well-defined. Do you have a use-case where this kind of dependence is desired?
cheers,
Tony
Miguel Branco
Apr 20, 2021, 3:05:05 AM4/20/21
to ki...@googlegroups.com
Hi,
In a multi-threaded environment, we can have two attributes being computed separately by two independent threads.
Attribute A is locking a parent node while recursing through a child (and trying to obtain a lock for that node). Attribute B, on another thread, is locking the child and trying to obtain a parent or something else locked. Attributes A and B are independent. This is totally harmless in general, but now that attributes are synchronized, the thread computing attribute A is holding a lock while trying to obtain another, while the thread computing attribute B is holding the other lock; so they deadlock.
We had this happen for instance as we had a shared tree used by all programs: a “standard library” tree of sorts, which all programs have access to. Each program is its own separate thread and normally is fully isolated. But as soon as attributes became synchronized, they were deadlocking. If we computed all attributes upfront for that shared tree first, all is ok (but somewhat clumsy to do as we do have many attrs). If we clone that standard library so that each program sees a different node, all is ok as well (better but slower).
I’m not sure what the right approach is here though. So far, this would have not been an issue, but adding synchronized to Kiama seems to indicate an intention to support muti-threaded environments. In that case, locking pairs of attribute/node sounded safer perhaps?
Cheers!
> --
> You received this message because you are subscribed to the Google Groups "kiama" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kiama+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kiama/2BE6573C-DC00-4339-B3AB-E68FE676F7DA%40gmail.com.
In a multi-threaded environment, we can have two attributes being computed separately by two independent threads.
Attribute A is locking a parent node while recursing through a child (and trying to obtain a lock for that node). Attribute B, on another thread, is locking the child and trying to obtain a parent or something else locked. Attributes A and B are independent. This is totally harmless in general, but now that attributes are synchronized, the thread computing attribute A is holding a lock while trying to obtain another, while the thread computing attribute B is holding the other lock; so they deadlock.
We had this happen for instance as we had a shared tree used by all programs: a “standard library” tree of sorts, which all programs have access to. Each program is its own separate thread and normally is fully isolated. But as soon as attributes became synchronized, they were deadlocking. If we computed all attributes upfront for that shared tree first, all is ok (but somewhat clumsy to do as we do have many attrs). If we clone that standard library so that each program sees a different node, all is ok as well (better but slower).
I’m not sure what the right approach is here though. So far, this would have not been an issue, but adding synchronized to Kiama seems to indicate an intention to support muti-threaded environments. In that case, locking pairs of attribute/node sounded safer perhaps?
Cheers!
> You received this message because you are subscribed to the Google Groups "kiama" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kiama+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kiama/2BE6573C-DC00-4339-B3AB-E68FE676F7DA%40gmail.com.
Tony Sloane
Jun 27, 2021, 9:57:32 PM6/27/21
to Kiama
Hi Manuel,
Sorry I haven’t responded more quickly. Life has been hectic and I haven’t had much time for Kiama.
Thanks for the report. I’ve created an issue so it doesn’t get lost:
Unfortunately, I don’t know when I will have time to look at it properly.
regards,
Tony
To view this discussion on the web visit https://groups.google.com/d/msgid/kiama/F044BE1A-ACA0-408C-A4BF-21BC2F338D6B%40spacebase.org.
Reply all
Reply to author
Forward
0 new messages