A Thread to Visual Basic

B

C

E

Or it could be:

Thread 1

A

B

C

D

E

Thread 2

B

C

E

or perhaps:

Thread 1

A

B

C

D

E

Thread 2

B

C

E

In other words, when you start a new thread of execution in an application, you can never know the exact order in which instructions in the two threads will execute relative to each other. The two threads are completely independent.

Why is this a problem?

A Multithreading Simulator

Consider the MTDemo project:

(You can download the sample code from ftp.desaware.com/SampleCode/Articles/Thread.zip)

The project contains a single code module that contains two global variables as follows:

'''' MTDemo - Multithreading Demo program
'''' Copyright © 1997 by Desaware Inc. All Rights Reserved

Option Explicit
Public GenericGlobalCounter As Long
Public TotalIncrements As Long

It contains a single form named frmMTDemo1 which contains the following code:

'''' MTDemo - Multithreading Demo program
'''' Copyright © 1997 by Desaware Inc. All Rights Reserved

Option Explicit
Dim State As Integer
	'''' State = 0 - Idle
	'''' State = 1 - Loading existing value
	'''' State = 2 - Adding 1 to existing value
	'''' State = 3 - Storing existing value
	'''' State = 4 - Extra delay	

Dim Accumulator As Long
Const OtherCodeDelay = 10

Private Sub Command1_Click()
	Dim f As New frmMTDemo1
	f.Show
End Sub

Private Sub Form_Load()
	Timer1.Interval = 750 + Rnd * 500
End Sub

Private Sub Timer1_Timer()
	Static otherdelay&
	Select Case State
		Case 0
			lblOperation = "Idle"
			State = 1
		Case 1
			lblOperation = "Loading Acc"
			Accumulator = GenericGlobalCounter
			State = 2
		Case 2
			lblOperation = "Incrementing"
			Accumulator = Accumulator + 1
			State = 3
		Case 3
			lblOperation = "Storing"
			GenericGlobalCounter = Accumulator
			TotalIncrements = TotalIncrements + 1
			State = 4
		Case 4
			lblOperation = "Generic Code"
			If otherdelay >= OtherCodeDelay Then
				State = 0
				otherdelay = 0
			Else
				otherdelay = otherdelay + 1
			End If
		End Select
	UpdateDisplay
End Sub

Public Sub UpdateDisplay()
	lblGlobalCounter = Str$(GenericGlobalCounter)
	lblAccumulator = Str$(Accumulator)
	lblVerification = Str$(TotalIncrements)
End Sub

This program uses a timer and a simple state machine to simulate multithreading. The State variable describes the five instructions that this program executes in order. State zero is an idle state. State one loads local variable with the GenericGlobalCounter global variable. State two increments the local variable. State three stores the result into the GenericGlobalCounter variable and increments the TotalIncrements variable (which counts the number of times that the GenericGlobalCounter variable has been incremented). State 4 adds an additional delay representing time spent running other instructions in the program.

The UpdateDisplay function updates three labels on the form that show the current value of the GenericGlobalCounter variable, the local accumulator, and the total number of increments.

Each timer tick represents a CPU cycle on the current thread. If you run the program you''''ll see that the value of the GenericGlobalCounter variable will always be exactly equal to the TotalIncrements variable -- which makes sense, because the TotalIncrements variable shows the number of times the thread has incremented the GenericGlobalCounter.

But what happens when you click the Command1 button and start a second instance of the form? This new form simulates a second thread.

Every now and then, the instructions will line up in such a way that both forms load the same GenericGlobalCounter value, increment it, and store it. As a result, the value will only increase by one, even though each thread believed that it had independently incremented the variable. In other words -- the variable was incremented twice, but the value only increased by one. If you launch several forms you will quickly see that the number of increments as represented by the TotalIncrements variable grows much more rapidly than the GenericGlobalCounter variable.

What if the variable represents an object lock count - which keeps track of when an object should be freed? What if it represents a signal that indicates that a resource is in use?

This type of problem can lead to resources becoming permanently unavailable to the system, to object being locked internally in memory, or freed prematurely. It can easily lead to application crashes.

This example was designed to make the problem easy to see -- but try experimenting with the value of the OtherCodeDelay variable. When the dangerous code is relatively small compared to the entire program, problems will appear less frequently. While this may sound g

上一页  [1] [2] [3] [4] [5] [6] [7]  下一页

Copyright ＠ 2007-2012 敏韬网(敏而好学，文韬武略--MinTao.Net)（学习笔记） Inc All Rights Reserved.
闵涛 E_mail:admin@mintao.net(欢迎提供学习资源)

鄂公网安备 42011102001154号

站长：MinTao ICP备案号：鄂ICP备11006601号-18