New to Threading Help please

New to Threading Help please

• easy_coder

  As for the Code i posted i'v totally dumped what i posted up ...As for the Windows Media Player well its not Embedded here it the link

  http://msdn.microsoft.com/library/default.asp url=/library/en-us/wmplay10/mmp_sdk/samples.asp

  That is what i'm using in my Project Windows Media Player SDK 10 samples...

  Did some looking in my Book and found this for a BackgroundWorker but i modified it a little bit....Still need to get the toolStripButton2 to Run the Windows Media Player from the SDK 10 Sample for dotnet C# that comes with the SDK....But I want the Player to run on its own background thread ,Thats what i'm trying to accomplish with the Code Below...Figured it might be easier to Utilize the Console and run it in the background...

  But yes as you can probably gather i want the Player to Utilize UI Threading,Not only for my project but to also get experience in Multi Threading..

  #region bgThread

  class BackgroundThread

  {

  public class MediaPlayer

  {

  public void MediaThread()

  {

  Console.WriteLine("-> {0} is executing MediaThread()",

  Thread.CurrentThread.Name);

  Thread.Sleep(2000);

  }

  class MediaViewer

  {

  static void Main(string[] args)

  {

  Console.WriteLine("**************Background Threads********\n");

  MediaPlayer p = new MediaPlayer();

  Thread bgroundThread =

  new Thread(new ThreadStart(p.MediaThread));

  bgroundThread.IsBackground = true;

  bgroundThread.Start();

  }

  }

  }

  #endregion

   

  
  

• Anonymous .

  Ok what i'm trying to Accomplish with the Threading is this...In my Main Program "MediaViewer" i have toolStripButton2 which i want too use to Execute the MediaPlayer" Using the Windows Media Player SDK 10 " at the moment...

  I have Imported the Windows Media Player SDK 10 dotnet Example for C# into my Main App "MediaViewer"....

  What i want it to do is when I click on the toolStripButton2 it will Run the Windows Media Player Example...Utilizing the Threading and BackgroundWorker so the Main App or System dosnt have to Work as Hard...

  what i'm trying to do is stated above

  I do plan on using a MemoryHelper also to reduce the System Load so it dosnt Utilize alot of System Memory...

  I know personally i cant stand a Application that uses a messload of memory and add's a *** load of additional process's for the CPU to keep track of,So i'm working on making an Application thats very Functional but Less System Intensive...

  
  

• Clarke Scott.

  The first thing that strikes me as odd in this example is that immediately after you create the thread, you have code that will sometimes try to abort the thread.

  First of all, never call Abort. It's a really bad idea. I wrote an explanation of why it's a really bad way to stop a thread (and what you should do instead) here: http://www.interact-sw.co.uk/iangblog/2004/11/12/cancellation

  Second, why don't you perform that check before you start the thread, and only start the thread if you're not going to abort it immediately afterwards E.g. something like this:

  private void toolStripButton2_Click(object sender, EventArgs e)
  {
  if (sender == toolStripButton2)
  {
  Application.Exit();
  }
  else
  {
  MediaThread = new Thread(new ThreadStart(this.RunMethod));
  MediaThread.Start(); // (See comment later in this post...)
  }
  }

  Next, could explain what you were trying to achieve here:

  Thread.CurrentThread.IsBackground.GetType();

  That line of code won't do anything useful. It will retrieve a Type object for System.Boolean, and then won't do anything with that object. In other words, it's a very long-winded way of doing absolutely nothing! I suspect that wasn't what you had in mind...

  If you could explain what you were hoping to do, I might be able to help with that.

  Finally, your call to MediaThread.Start is in the wrong place. You've put it inside your RunMethod. RunMethod is the method you passed in as your ThreadStart, so RunMethod won't run until you start the thread. So by putting the call to MediaThread.Start inside your RunMethod you've created a bit of a chicken-and-egg bootstrap problem...

  The call to a Thread's Start() method has to be made by a thread that's already running - it can't be made by the thread you're trying to start, because you've got to start the thread before that new thread can do anything! So you usually call Start() from the same thread you created the new Thread from.

  In your example, you're creating the new Thread from the UI thread. (The UI thread manages all user interface interactions. Any control event handlers you register, such as this Click handler, will run on the UI thread.)

  So you should call Start on that thread, immediately after creating the new Thread.

  The example code I've shown above does exactly that. I've highlighted the relevant line in bold.

  You also said this:

  "C# Books they help some but the book ALWAYS use Console and dont give too much code for Forms..."

  Well, OK, but all the things you've done wrong so far have been entirely unrelated to Forms. The things you've done wrong would also have been wrong if you'd done them in a Console app. It might be worth trying some simple experiments in Console apps first just to get yourself more familiar with the threading APIs.

  But if you're looking for articles that talk about threading and Windows Forms, you might want to read this article I wrote for MSDN magazine a few years ago:

  http://msdn.microsoft.com/msdnmag/issues/03/02/Multithreading/default.aspx

  It's all .NET 1 I'm afraid, so it makes no mention of the BackgroundWorker. That was introduced in .NET 2.0, and it's actually a better way of doing things now than the way I suggest in that article. However, I tried to explain a lot of the important threading concepts specific to Windows Forms, so you might find it interesting.

  
  

• heri_09

  Rattlerr wrote:

  what i'm trying to do is stated above

  Yes, but you still didn't answer my question. I asked why you wrote this:

  Thread.CurrentThread.IsBackground.GetType();

  It was unclear to me what you were trying to achieve with this line of code. It's still unclear to me what you are trying to achieve with this line of code. I read your original question and I've read your second post, and it's still completely unclear how you think this line of code fits into the overall picture of what you were trying to achieve.

  I wasn't asking what the overall goal was - I was trying to help you with your code, so I was trying to understand what specific purpose you had in mind for that line of code.

  So with respect, I don't think you did state what that line of code was for in your original post, and I don't think you've stated it in your reply either.

  Also, I suspect that the way you're trying to use threading here will not have the effect you're looking for. You say you want to:

  Rattlerr wrote:

  ..."Run the Windows Media Player Example...Utilizing the Threading and BackgroundWorker so the Main App or System dosnt have to Work as Hard...

  Moving work to a different thread doesn't reduce the amount of work the application or the system has to do. Quite the opposite in fact. Not only will the system still have to do all the same work as before, there is now the extra overhead of the fact that you're doing it on a separate thread!

  Threads don't reduce system load. That's not what they're for. They're there to enable multiple execution contexts to operate concurrently.

  Rattlerr wrote:

  I know personally i cant stand a Application that uses a messload of memory and add's a *** load of additional process's for the CPU to keep track of,

  In that case you should be aware that every thread you create uses extra memory and uses more CPU.

  There is a good reason for using threads in a Windows Forms application. The reason is to enable slow work to be done without making the UI unresponsive. For example if you send a complex query to a database server, and that query takes several seconds to execute, you should use a worker thread to do this. If you don't use a worker thread, you will make the UI unresponsive to user input for the duration of the query.

  This is not a CPU load problem. In fact the client machine will be idle - it will use no CPU time while it sits and waits for a response from the database server. But it will be unresponsive while it sits and waits. So you end up with the irony with a machine with a very low CPU utilization, but which is unresponsive, and therefore seems slow to the user.

  By using a worker thread, you increase the overheads on the system - you'll use more memory and more CPU time - but in exchange for that it becomes possible to improve responsiveness.

  So, given the goals you've stated, threads will achieve the exact opposite of what you say have set out to do. They will increase the CPU load on the client, and they will increase the memory usage.

  But it's possible they will result in an application that will seem faster to the end user, despite the increased system load.

  It's also quite common for the use of threads to make things worse in every respect... Multithreading is difficult, and a lot of multithreaded applications end up being slower, using more memory, and being less reliable than a single-threaded equivalent could have been.

  In short, threads are potentially powerful, but they can be expensive and they can be dangerous.

  By the way, is this the example you're referring to

  http://msdn.microsoft.com/library/default.asp url=/library/en-us/wmplay10/mmp_sdk/embeddingtheplayercontrolinacapplication.asp

  If so, you may have yet more problems! If you're using the control, you're going to encounter problems using that from anything other than the UI thread. The Windows Forms threading model forbids it. Controls have to be used from the UI thread.

  
  
• New to Threading Help please