Hi all,
Recently, I found myself fishing for this capability. My use case was, in
an earlier PR, I wrote up a code like this
```
func foo(bar *typ) bool {
bar.mutex.RLock()
*defer bar.mutex.RLock() /*/ use bar.attributes in a read only mode and
compute a bool value
}
```
This was an egregious oversight and because this file was a rather long
one. It took a whole to work out the root cause. One idea I had was as part
of our unit testing modules while asserting the final states, I'd try
acquire in shared and exclusive mode, if either fails, I'll fail the test.
I read through various arguments and i 100% support that production code
shouldn't use try locks. They either use exclusive locks or mvcc style or
channels. But did this testing oriented usecase come up at all? We run go
test -race as part of tests too. So it appears race detector doesn't detect
these problems either. Wondering if there are other ways for me to
accomplish what i'm after here.
Best,
Subbu
On Tuesday, August 13, 2013 at 8:57:54 PM UTC-7 [email protected] wrote:
> Sorry, I changed my mind mid-way through and forgot to edit. I think
> they're about equally clean.
>
>
> On Tuesday, August 13, 2013 11:35:27 PM UTC-4, kortschak wrote:
>>
>> On Tue, 2013-08-13 at 19:46 -0700, Joshua Liebow-Feeser wrote:
>> > I'll show my use case, which I think is considerably cleaner with
>> > TryLock than with channels.
>>
>>
>> > Contrary to what some have said, the TryLock example doesn't strike me
>> > as any more complex than the channel example. They strike me as about
>> > the same level of complexity.
>> >
>> Which is it? Cleaner or the same level of complexity? Or both?
>>
>> The select is very clean.
>>
>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/91deec2d-53a9-4215-a7f9-060a33658d3an%40googlegroups.com.
