Race conditions - Revision history

JaroslavTulach: /* Test to Simulate Race conditions */

2018-10-20T05:38:09Z

Test to Simulate Race conditions

←Older revision		Revision as of 05:38, 20 October 2018
Line 24:		Line 24:
	os.close()		os.close()
	</source>		</source>
-	The above code can be interrupted at any time by the system. Instead of executing all the code as an atomic operation, the control can be passed to ~~the~~ competing process which [[race conditions\|races]] to perform the same actions.	+	The above code can be interrupted at any time by the system. Instead of executing all the code as an atomic operation, [[OS]] can suspend the process and the control can be passed to a competing process which [[race conditions\|races]] to perform the same actions.
	* What happens when one process creates the file, and another tries to read it meanwhile, before a port number is written to it?		* What happens when one process creates the file, and another tries to read it meanwhile, before a port number is written to it?
	* What if there is a file left from a previous (killed) execution?		* What if there is a file left from a previous (killed) execution?

JaroslavTulach: /* Simple FlowControlingTest written manually */

2018-10-20T05:35:00Z

Simple FlowControlingTest written manually

←Older revision		Revision as of 05:35, 20 October 2018
Line 30:		Line 30:
	All these questions have to be asked when one wants to have really good confidence in the application code.		All these questions have to be asked when one wants to have really good confidence in the application code.

-	== Simple [[~~FlowControlingTest~~]] written manually ==	+	== Simple [[FlowControllingTest]] written manually ==

	In order to get the confidence we wanted, we inserted a lot of check points into our [https://github.com/jtulach/incubator-netbeans/blob/9.0-vc3/o.n.bootstrap/src/org/netbeans/CLIHandler.java#L514 implementation of locking ] so the code became a modified version of the previous snippet:		In order to get the confidence we wanted, we inserted a lot of check points into our [https://github.com/jtulach/incubator-netbeans/blob/9.0-vc3/o.n.bootstrap/src/org/netbeans/CLIHandler.java#L514 implementation of locking ] so the code became a modified version of the previous snippet:

JaroslavTulach: /* Test to Simulate Race conditions */

2018-10-20T05:34:46Z

Test to Simulate Race conditions

←Older revision		Revision as of 05:34, 20 October 2018
Line 28:		Line 28:
	* What if there is a file left from a previous (killed) execution?		* What if there is a file left from a previous (killed) execution?
	* What happens when a test for file existence fails, but when trying to create it the file already exists?		* What happens when a test for file existence fails, but when trying to create it the file already exists?
-	All these questions have to be asked when one wants to have really good confidence in the application code. In order to get the confidence we wanted, we inserted a lot of check points into our [https://github.com/jtulach/incubator-netbeans/blob/9.0-vc3/o.n.bootstrap/src/org/netbeans/CLIHandler.java implementation of locking ] so the code became a modified version of the previous snippet:	+	All these questions have to be asked when one wants to have really good confidence in the application code.
		+
		+	== Simple [[FlowControlingTest]] written manually ==
		+
		+	In order to get the confidence we wanted, we inserted a lot of check points into our [https://github.com/jtulach/incubator-netbeans/blob/9.0-vc3/o.n.bootstrap/src/org/netbeans/CLIHandler.java#L514 implementation of locking ] so the code became a modified version of the previous snippet:
	<source lang="java">		<source lang="java">
	enterState(10, block);		enterState(10, block);
Line 47:		Line 51:
	enterState(22, block);		enterState(22, block);
	os.writeInt(p);		os.writeInt(p);
-	enterState(23, block);	+	enterState(23, block);
		+	os.close();
	</source>		</source>
		+
	The '''enterState''' method does nothing in real production environment, but in test it can be instructed to block at a specific check point. So we can write a test which starts two threads and instruct one of them to stop at 22 and then let the second one run and observe how it handles the case when a file already exists, but the port is not yet written in.		The '''enterState''' method does nothing in real production environment, but in test it can be instructed to block at a specific check point. So we can write a test which starts two threads and instruct one of them to stop at 22 and then let the second one run and observe how it handles the case when a file already exists, but the port is not yet written in.

JaroslavTulach: /* Test to Simulate Race conditions */

2018-10-20T05:29:55Z

Test to Simulate Race conditions

←Older revision		Revision as of 05:29, 20 October 2018
Line 24:		Line 24:
	os.close()		os.close()
	</source>		</source>
-	The above code can be interrupted at any time by the system ~~and instead~~ of executing all ~~of this~~ as an atomic operation, the control can be passed to the competing process which ~~does~~ the same actions.	+	The above code can be interrupted at any time by the system. Instead of executing all the code as an atomic operation, the control can be passed to the competing process which [[race conditions\|races]] to perform the same actions.
	* What happens when one process creates the file, and another tries to read it meanwhile, before a port number is written to it?		* What happens when one process creates the file, and another tries to read it meanwhile, before a port number is written to it?
	* What if there is a file left from a previous (killed) execution?		* What if there is a file left from a previous (killed) execution?

JaroslavTulach: /* Test to Simulate Race conditions */

2018-10-20T05:29:01Z

Test to Simulate Race conditions

←Older revision		Revision as of 05:29, 20 October 2018
Line 21:		Line 21:
	SocketServer server = new SocketServer();		SocketServer server = new SocketServer();
	int p = server.getLocalPort();		int p = server.getLocalPort();
-	os.writeInt(p);	+	os.writeInt(p);
		+	os.close()
	</source>		</source>
	The above code can be interrupted at any time by the system and instead of executing all of this as an atomic operation, the control can be passed to the competing process which does the same actions.		The above code can be interrupted at any time by the system and instead of executing all of this as an atomic operation, the control can be passed to the competing process which does the same actions.

JaroslavTulach: /* Test to Simulate Race conditions */

2018-10-20T05:28:26Z

Test to Simulate Race conditions

←Older revision		Revision as of 05:28, 20 October 2018
Line 7:		Line 7:
	We have faced such problem when asked to write a [http://openide.netbeans.org/proposals/arch/cli.html startup lock] for [[NetBeans]]. The goal was to solve a situation when a user starts the [[NetBeans]] IDE for the second time and warn him that another instance of the program is already running and then exit. This is similar to the behaviour of Mozilla or Open Office. We decided to allocate a socket server and create a file in a well known location with the port number written to it. Then each newly started [[NetBeans]] IDE could verify whether a previously running instance is active or not (by reading the port number and trying to communicate with it).		We have faced such problem when asked to write a [http://openide.netbeans.org/proposals/arch/cli.html startup lock] for [[NetBeans]]. The goal was to solve a situation when a user starts the [[NetBeans]] IDE for the second time and warn him that another instance of the program is already running and then exit. This is similar to the behaviour of Mozilla or Open Office. We decided to allocate a socket server and create a file in a well known location with the port number written to it. Then each newly started [[NetBeans]] IDE could verify whether a previously running instance is active or not (by reading the port number and trying to communicate with it).

-	The major problem we had to optimize for was a situation when the user starts more [[NetBeans]] IDE processes at once. This can happen by extra clicks on the icon on the desktop or by dragging and dropping more files on the desktop icon of the IDE. Then more processes are started and they ~~start to~~ compete ~~for~~ the ~~file and its content~~. The sequence of one process looks like this:	+	The major problem we had to optimize for was a situation when the user starts more [[NetBeans]] IDE processes at once. This can happen by extra clicks on the icon on the desktop or by dragging and dropping more files on the desktop icon of the IDE. Then more processes are started and they [[Race conditions\|compete] to lock the user directory. The sequence of one process looks like this:
	<source lang="java">		<source lang="java">
	if (lockFile.exists ()) {		if (lockFile.exists ()) {

JaroslavTulach: /* Test to Simulate Race conditions */

2018-10-20T05:27:32Z

Test to Simulate Race conditions

←Older revision		Revision as of 05:27, 20 October 2018
Line 7:		Line 7:
	We have faced such problem when asked to write a [http://openide.netbeans.org/proposals/arch/cli.html startup lock] for [[NetBeans]]. The goal was to solve a situation when a user starts the [[NetBeans]] IDE for the second time and warn him that another instance of the program is already running and then exit. This is similar to the behaviour of Mozilla or Open Office. We decided to allocate a socket server and create a file in a well known location with the port number written to it. Then each newly started [[NetBeans]] IDE could verify whether a previously running instance is active or not (by reading the port number and trying to communicate with it).		We have faced such problem when asked to write a [http://openide.netbeans.org/proposals/arch/cli.html startup lock] for [[NetBeans]]. The goal was to solve a situation when a user starts the [[NetBeans]] IDE for the second time and warn him that another instance of the program is already running and then exit. This is similar to the behaviour of Mozilla or Open Office. We decided to allocate a socket server and create a file in a well known location with the port number written to it. Then each newly started [[NetBeans]] IDE could verify whether a previously running instance is active or not (by reading the port number and trying to communicate with it).

-	The major problem we had to optimize for was ~~to solve~~ situation when the user starts more [[NetBeans]] ~~IDEs~~ at once. This can happen by extra clicks on the icon on the desktop or by dragging and dropping more files on the desktop icon of the IDE. Then more processes are started and they start to compete for the file and its content. The sequence of one process looks like this:	+	The major problem we had to optimize for was a situation when the user starts more [[NetBeans]] IDE processes at once. This can happen by extra clicks on the icon on the desktop or by dragging and dropping more files on the desktop icon of the IDE. Then more processes are started and they start to compete for the file and its content. The sequence of one process looks like this:
	<source lang="java">		<source lang="java">
	if (lockFile.exists ()) {		if (lockFile.exists ()) {

JaroslavTulach: /* Test to Simulate Race conditions */

2018-10-20T05:26:16Z

Test to Simulate Race conditions

←Older revision		Revision as of 05:26, 20 October 2018
Line 5:		Line 5:
	While certain problems with multiple threads and their synchronization are hard to anticipate, as [[deadlock]]s mentioned [[FlowControllingTest\|earlier]], sometimes it is possible and useful to write a test to verify that various problems with parallel execution are correctly handled.		While certain problems with multiple threads and their synchronization are hard to anticipate, as [[deadlock]]s mentioned [[FlowControllingTest\|earlier]], sometimes it is possible and useful to write a test to verify that various problems with parallel execution are correctly handled.

-	We have faced such problem when ~~we were~~ asked to write a [http://openide.netbeans.org/proposals/arch/cli.html startup lock] for [[NetBeans]]. The goal was to solve a situation when a user starts the [[NetBeans]] IDE for the second time and warn him that another instance of the program is already running and then exit. This is similar to the behaviour of Mozilla or Open Office. We decided to allocate a socket server and create a file in a well known location with the port number written to it. Then each newly started [[NetBeans]] IDE could verify whether a previously running instance is active or not (by reading the port number and trying to communicate with it).	+	We have faced such problem when asked to write a [http://openide.netbeans.org/proposals/arch/cli.html startup lock] for [[NetBeans]]. The goal was to solve a situation when a user starts the [[NetBeans]] IDE for the second time and warn him that another instance of the program is already running and then exit. This is similar to the behaviour of Mozilla or Open Office. We decided to allocate a socket server and create a file in a well known location with the port number written to it. Then each newly started [[NetBeans]] IDE could verify whether a previously running instance is active or not (by reading the port number and trying to communicate with it).

	The major problem we had to optimize for was to solve situation when the user starts more [[NetBeans]] IDEs at once. This can happen by extra clicks on the icon on the desktop or by dragging and dropping more files on the desktop icon of the IDE. Then more processes are started and they start to compete for the file and its content. The sequence of one process looks like this:		The major problem we had to optimize for was to solve situation when the user starts more [[NetBeans]] IDEs at once. This can happen by extra clicks on the icon on the desktop or by dragging and dropping more files on the desktop icon of the IDE. Then more processes are started and they start to compete for the file and its content. The sequence of one process looks like this:

JaroslavTulach at 05:25, 20 October 2018

2018-10-20T05:25:48Z

←Older revision		Revision as of 05:25, 20 October 2018
Line 3:		Line 3:
	== Test to Simulate [[Race conditions]] ==		== Test to Simulate [[Race conditions]] ==

-	While certain problems with multiple threads and their synchronization are hard to anticipate, as [[deadlock]]s mentioned earlier, sometimes it is possible and useful to write a test to verify that various problems with parallel execution are correctly handled.	+	While certain problems with multiple threads and their synchronization are hard to anticipate, as [[deadlock]]s mentioned [[FlowControllingTest\|earlier]], sometimes it is possible and useful to write a test to verify that various problems with parallel execution are correctly handled.

	We have faced such problem when we were asked to write a [http://openide.netbeans.org/proposals/arch/cli.html startup lock] for [[NetBeans]]. The goal was to solve a situation when a user starts the [[NetBeans]] IDE for the second time and warn him that another instance of the program is already running and then exit. This is similar to the behaviour of Mozilla or Open Office. We decided to allocate a socket server and create a file in a well known location with the port number written to it. Then each newly started [[NetBeans]] IDE could verify whether a previously running instance is active or not (by reading the port number and trying to communicate with it).		We have faced such problem when we were asked to write a [http://openide.netbeans.org/proposals/arch/cli.html startup lock] for [[NetBeans]]. The goal was to solve a situation when a user starts the [[NetBeans]] IDE for the second time and warn him that another instance of the program is already running and then exit. This is similar to the behaviour of Mozilla or Open Office. We decided to allocate a socket server and create a file in a well known location with the port number written to it. Then each newly started [[NetBeans]] IDE could verify whether a previously running instance is active or not (by reading the port number and trying to communicate with it).

JaroslavTulach at 05:25, 20 October 2018

2018-10-20T05:25:15Z

←Older revision		Revision as of 05:25, 20 October 2018
Line 1:		Line 1:
	There is no such thing as 100% [[CodeCoverage]], but that doesn't mean we shouldn't strive to increase [[BugFixCoverage]]. The [[FlowControllingTest]] test pattern make it possible to even test [[race conditions]].		There is no such thing as 100% [[CodeCoverage]], but that doesn't mean we shouldn't strive to increase [[BugFixCoverage]]. The [[FlowControllingTest]] test pattern make it possible to even test [[race conditions]].

-	== Test to Simulate [[Race ~~Conditions~~]] ==	+	== Test to Simulate [[Race conditions]] ==

	While certain problems with multiple threads and their synchronization are hard to anticipate, as [[deadlock]]s mentioned earlier, sometimes it is possible and useful to write a test to verify that various problems with parallel execution are correctly handled.		While certain problems with multiple threads and their synchronization are hard to anticipate, as [[deadlock]]s mentioned earlier, sometimes it is possible and useful to write a test to verify that various problems with parallel execution are correctly handled.