Re: simplest thread safe pattern

Tech-Archive recommends: Fix windows errors by optimizing your registry

I hate to be the bad guy, but since you asked for the best way to accomplish it... You should seriously consider refactoring your code. For starters, you mentioned you have a class with hundreds of methods. That should be a big red flag right there.

Second of all, it sounds like you're not really sure what's safe to parallelize and what isn't. You should re-think the problem and design your code to be more task-oriented and self-contained. If you created several smaller classes that had no external dependencies, you could simply new up a bunch of them and throw them onto the threadpool.

Finally, if it starts to sound very confusing and a lot of work, you should re-consider whether or not you need to do this on multiple threads. The truth is, multithreaded programming is HARD and it can't be solved simply by using broad locks, otherwise you may as well not have any threads at all.

Josh Einstein

"John A Grandy" <johnagrandy-at-gmail-dot-com> wrote in message news:#Pcx5prcJHA.3520@xxxxxxxxxxxxxxxxxxxxxxx
Yikes. That's not what I want.

What I want is for at most one thread to be executing code in each of my class' public methods that performs data-access.

What is the best way to accomplish this ?


"John A Grandy" <johnagrandy-at-gmail-dot-com> wrote in message news:%23QkIU3pcJHA.4440@xxxxxxxxxxxxxxxxxxxxxxx
<<<
Once method is entered, all other methods need to wait. Even those
methods that
could be capable of returning result without interference with other
parts of
code are on wait. No matter how many threads you have, only one is
allowed access
at any point in time.


My understanding is that this attribute implements a per-method lock. While a thread is executing code inside the specific locked method , all other threads will need to wait until the current thread exits.

Other methods in the class ( even those that are locked in identical fashion ) are not affected the lock.

Is this correct ?


Here's an example that outlines my thinking :

using System;
using System.Collections.Generic;
using System.Runtime.CompilerServices;
using System.Text;

namespace Namespace1
{
public class Class1
{
// external threads repeatedly call Method1,Method2,Method1, etc.

[MethodImplAttribute( MethodImplOptions.Synchronized )]
public void Method1()
{
// thread #2 currently executing here,
// when finished will wait for thread #1 to exit Method2
}

[MethodImplAttribute( MethodImplOptions.Synchronized )]
public void Method2()
{
// thread #1 currently executing here,
// when finished, will wait for thread #2 to exit Method1
}

}
}


"Josip Medved" <jmedved@xxxxxxxxxxx> wrote in message news:71d952b9-947b-44d5-92aa-3a296fcca63f@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
... so , [MethodImplAttribute(MethodImplOptions.Synchronized )] is just
some special magic which accomplishes same behind the scenes ... ?

No, it does something like this

public void Method1() {
lock {
//some code
}
}

Interestingly, on adding this attribute to all of my public methods that
perform data-access , all of my System.Data.SqlClient concurrency-related
exceptions magically went away.

That is because if you add this to all your methods there is no real
concurency.

What are the practical drawbacks of using this attribute on a per-method
basis ?

Once method is entered, all other methods need to wait. Even those
methods that
could be capable of returning result without interference with other
parts of
code are on wait. No matter how many threads you have, only one is
allowed access
at any point in time.

Often this is too restrictive. Most usual scenario (at least for me)
is having few
writes of data and many reads. In that case ReaderWriterLock gives you
real
performance boost (in this case lock does really bad).

Also having multiple lock objects if your class does some things that
are not
in close relation gives nice boost.

However to give real advice what to use, one always needs to see code
and how that
code is to be used and thus I gave advice to just put lock everywhere
and MEASURE
where you have a preformance problem. There is no sense (IMHO) to make
perfect
arhitecture to squeze every possible nanosecond. If your program is
slow, just
optimize few methods that do have a problem and you will see huge
performance
boost (80/20 rule applies). Time spent on optimizing something that
your customer
will not feel is wasted time better spent on testing and debugging.

There is not many applications where every processor clock is so
precious that
everything needs to be perfect (and I have my doubts that anybody
writes those
applications in C#).

--
Josip Medved
http://www.jmedved.com
http://medo64.blogspot.com



.

Relevant Pages

  • Re: simplest thread safe pattern
    ... The actual threads in my app are spawned in higher-layer code -- this higher-layer code knows nothing of how data-access is implemented. ... While a thread is executing code inside the specific locked method, all other threads will need to wait until the current thread exits. ... Other methods in the class (even those that are locked in identical fashion) are not affected the lock. ... public void Method1() ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: simplest thread safe pattern
    ... What I want is for at most one thread to be executing code in each of my ... My understanding is that this attribute implements a per-method lock. ... public void Method1() ... performance boost. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: thread-safety
    ... It supports immediate addition to the consumer's queue, and creation of a repeating timer that will periodicially add to the consumer's queue. ... private TimeSpan _tsExecute; ... // the JobConsumer class while holding it's own lock. ... public void Add ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: thread-safety
    ... and I started to use dotnet's queue collection with lock protection. ... private enum WorkerThreadState; ... private object stateLocker = new object; ... public void Start ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Shared memory across threads
    ... I tried to reproduce your problem and finally it worked fine for me using a lock on the SyncRoot property of the ArrayList instance. ... private Thread _t1; ... public void ShowItems() ...
    (microsoft.public.dotnet.general)