What's suboptimal with the first one (or the second one) is that if
performOperation1() panics the lock will not be released. It may or may not
be a problem depending on the situation. Your assessment of defer used with
locks is correct - it works well only if the lock doesn't need to be
released before the end of the function - but in my experience you can
always extract a function to achieve that. If you can't, it's usually a
sign that the code needs some reworking.
On Friday, February 8, 2019 at 7:03:28 PM UTC-5, Michael Jones wrote:
>
> I don’t see anything suboptimal about the first one.
>
> Defer is a function-scope magic thing.
>
> Go designers chose not to have lexical scope magic, so you would either
> force function scope (prior answer) or be happy with the normal code.
>
> On Fri, Feb 8, 2019 at 10:31 AM Burak Serdar <bse...@ieee.org
> <javascript:>> wrote:
>
>> On Fri, Feb 8, 2019 at 11:28 AM vincent163 <hwy14...@gmail.com
>> <javascript:>> wrote:
>> >
>> > I am thinking about how to write programs like this:
>> > lock1.Lock()
>> > err = performOperation1()
>> > if err != nil {
>> > lock1.Unlock()
>> > return err
>> > }
>> > lock1.Unlock()
>> > performExpensiveOperation2()
>>
>> How about this:
>>
>> lock1.Lock()
>> err = performOperation1()
>> lock1.Unlock()
>> if err != nil {
>> return err
>> }
>> performExpensiveOperation2()
>>
>>
>> >
>> >
>> > The lock1 must be locked while performing operation1, and I need to use
>> its result to perform operation2. Since operation2 is expensive, I don't
>> want to hold the lock while performing it, and lock1.Unlock() needs to be
>> called before calling operation2.
>> > Go's defer mechanism doesn't seem to handle this case well since the
>> resource is used only within a block and not throughout the function. Is
>> there a recommended way to write programs in this case?
>> > I know I could wrap the lock block in a closure, but that creates a
>> completely new scope, so I can't return directly or break out of a loop
>> within the closure, etc.
>> >
>> > --
>> > 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 golang-nuts...@googlegroups.com <javascript:>.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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 golang-nuts...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
>
> *Michael T. jonesmichae...@gmail.com <javascript:>*
>
--
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
