3

Can I use it like I've described in the current code?

private void Increment() {
    lock(LockObject) {      
         // edit
         // ListOfObjects.Add(someInfo);
         // new edit ---> here
         ListOfObjects.Add(new SomeInfoObject() {
             Account = Interlocked.Increment(ref result),
             // ... other properties
         }
         // Interlocked.Increment(ref result);
    }
}
hackp0int
  • 4,052
  • 8
  • 59
  • 95
  • Yes you can but you shouldn't in this case. You're only adding extra overhead. But when it's part of a larger section of code inside a lock, fine. – H H Oct 09 '13 at 11:16

3 Answers3

3

lock is not required when you use Interlocked class.

MSDN says,

Increments a specified variable and stores the result, as an atomic operation.

Rajesh Subramanian
  • 6,400
  • 5
  • 29
  • 42
  • 3
    It kind of depends whether there's anything else inside the lock block and what you're locking on. For instance it could make sense to increment something that's totally unrelated to the lock with Interlocker.Increment. – Matti Virkkunen Oct 09 '13 at 11:15
  • Yes if you have more statements inside the lock construct, then you can do that. From the question's context, it is not required – Rajesh Subramanian Oct 09 '13 at 11:18
3

Yes you can, but there should be no reason to do it. Both lock and interlocked operations work only if all parties involved agreed to do the same. If one thread uses lock, expecting that nothing can change while holding the lock, and another thread one uses ICX then the ICX thread has just violated the assumptions of the first thread. If both threads agree to use lock then the use of ICX inside lock is questionable. A single statement lock that all it does is an ICX is very very unusual.

You need to post a more detailed description of the code explaining the actual problem you're trying to solve.

Remus Rusanu
  • 288,378
  • 40
  • 442
  • 569
1

You can use it, but is redundant in this case, since nothing else is being protected by the lock block.

Take a look at this post for more info.

--- EDIT ---

OK, I see you edited the question to add something to the lock block.

In that case, it makes sense to protect this other operation, but whether it also makes sense to put Interlocked.Increment inside the lock block depends on what you are trying to accomplish.

Could you provide more context?

Community
  • 1
  • 1
Branko Dimitrijevic
  • 50,809
  • 10
  • 93
  • 167
  • What context do you mean? – hackp0int Oct 09 '13 at 11:26
  • @IamStalker Essentially, what the rest of the code is doing and what is the end-goal you are trying to accomplish. – Branko Dimitrijevic Oct 09 '13 at 11:26
  • Just to know if this locking and atomic operations to use in this context? – hackp0int Oct 09 '13 at 11:27
  • @IamStalker If you have only one thread, then you need neither `lock` nor `Interlocked.Increment`. If you have other threads, please tell us what they are doing. – Branko Dimitrijevic Oct 09 '13 at 11:29
  • @IamStalker If `Increment` is not called from multiple threads, then neither is needed. If it is, and it's the only place where `result` is is used, then you don't need `Interlocked.Increment(ref result)` (you still need the `lock`). Otherwise, you need to protect `result` somehow - which _may_ be `Interlocked.Increment`, or _may_ be this `lock` or _may_ be some other `lock`, depending on the situation... – Branko Dimitrijevic Oct 09 '13 at 11:51
  • Sorry I didn't understood you – hackp0int Oct 09 '13 at 11:59