Xiaobai begged for guidance, the problem of multi threaded ticket sales, why the first ticket is alw

From your point of view, you are considered 2 ticket-buying systems, and the 2 threads have not operated the same variable, one thread operates in xc1, and the other operates in xc2, which will definitely not achieve the effect you expect.

Because the first one is sharing a resource m, and the second one is not sharing each with their own 5 tickets.

Because your synchronized is written in the while loop, in if.

There are a total of 6 threads, all of which are judged (ticket>0), and then stuck in the synchronized** block.

That is to say, at a certain point in time, when the rise is late, these six threads have passed the judgment of ticket>0, and then the synchronized ** segment is executed sequentially. So that's what this result looks like.

If you want to achieve the desired effect, you can add the judgment of the bet off, or put synchronized out of the loop.

You need to figure out that both of your threads are sharing the same member variable tickets, and you're using thread synchronization.

When the first thread finishes running, i.e. when tickets=0, the first thread ends.

The second thread starts running, but at this point tickets=0, so the second thread goes into else.

So just jump out of this loop, and the result will definitely only show the result of the first thread run.

The point is that you want to figure out that these two threads share the same variable.

You have two questions here.

First: change the main method:

a aa = new a();

a aaa = new a();

thread t1 = new thread(aa);

thread t2 = new thread(aaa);

The original definition of t1 and t2 is actually one thread, but now it is two threads.

Second: if you want to buy a ticket for thread-0 and 1 to interleave, you should remove synchronized (str), but that depends on your specific requirements.

Because your program is always running in a thread, of course. You open a few more programs and see if they all start and see if the effect is what you want. One program per thread, start multiple myeclipse running the program at the same time.

The phrase synchronized (str) should be removed.

Otherwise, both threads will have to use the shared resource str, and they will have to queue up.

Khan: Your threads haven't slept, they have been occupying locks, and other threads can't get resources, so of course one thread will run.

It should be a problem with your machine settings, my machine is normal.

The lock has been occupied, and it has not been released

This is the simplest application of multithreading. You can write it by looking at the book a little.

In this case, if there is a shared resource between multiple threads, be sure to add a synclock to the ** that operates the shared resource. Just like the print statement and the --tickets statement in your **, you need to add a synclock, and you can't let them execute separately between multiple threads, otherwise it will fail. Because the scheduling of threads is determined by the operating system, the order in which threads are executed and the timing of switching are not determined.

If you do this many times, there will definitely be different printing results, I don't believe you might as well try.

The specific execution process after the occurrence of 98 in 97 should be:

After thread 0 prints 99, before --tickets, the system executes thread 1, gets 99 and prints, executes thread 0's --tickets, and assigns this value to the tickets variable in the print statement (maybe it is executed, and then the system executes thread 1's --tickets**, and continues to print 97, and then continues to 96, 95, and then goes back to execute the print statement of thread 0, Because the tickets in it are still the value assigned last time, instead of taking the new value at this time, it is printed out 98

The key knowledge point here is that when your print statement is compiled into the final machine code for execution, it is multiple statements instead of one, which can be disassembled and executed, so this problem will occur. Therefore, it must be added with a synclock so that it cannot be disassembled and executed.

This is caused by the thread being out of sync, thread-0 has read 98, but before it can be output, the time slice has been allocated to thread 1, so the next thing is the ticket sold by thread-1. When the next time slice is redistributed to thread-0, 98 is outputBut by that time, Thread-1 had already sold its 95th sheet.

So the output shows 98 behind 97, 96, 95.

The landlord's problem lies in the multi-threaded concurrent execution, although the order of execution of statements in each thread is determined, but the relative order of execution of threads is uncertain. Generally harmless, but this procedure creates uncertainty.

In the main method, t1 and t2 are two concurrent threads, and the computer schedules them and you don't take any control measures, such as synchronized(this) to add blockade control. When t1 reads out the ticket selling information and is about to execute --tickets, the t2 thread is concurrent, and it will re-execute, resulting in an error message.

Does the landlord understand.

From 99 0 enters Print not -- when 1 enters Print --1 process at this time 0 is 99 1 is also 99).

Then at this time, 0 threads minus 1, 0 threads get called again, but when the judgment is executed, the output is not executed for a long time, and the --2 process is delayed, at this time, 0 should be 98, but it is not printed).

2 process at 0 thread if and during 1 thread also minus 1 at this point it will be 97 printed out ---3 process).

1. Thread calls to 95 ---4 process) normally), at this time, the print statement of 2 process is executed, so 0 thread is 98, and you can use synchronized(this) to control concurrency.

class mythread2 is mythread2

MythRead MT is MyThread. Not the same class.

It should be mythread2 mt = new mythread2();

Make a game to play. For example, tank battles and the like, the main thread records keyboard and mouse movements, determines whether it hits, etc., and the background thread refreshes and redraws the interface.

Because you're not implementing thread synchronization.

The ** you wrote does not implement thread synchronization, and each thread that is opened will use the tick variable, so the above problem will occur.

Solution: Add a lock to variables in a multi-threaded environment.

Synchronized (this) block contains -- why synchronized (this) block is used

In fact, you can do without this, as long as it is an object, each object has a "lock flag", and multithreading is based on the "lock flag" of the object passed in the synchronized ("object") block

to achieve synchronization.

this is an object of this class.

If you write like this, the result of the run is certainly not unique, because you can't guarantee that there will only be one thread to modify the value of the tick. If both threads are running to"sell tickets:"+tick);

This sentence has not yet come to tick--; It's just two outputs.

There are two different people who sell tickets every time, the first line sells 1sell, the second line sells 0sell, and the first time they sell it, of course they are all 100.