This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 16344 - Does Mutex.post.*Request behave correctly?
Summary: Does Mutex.post.*Request behave correctly?
Status: CLOSED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: anovak
URL:
Keywords:
Depends on:
Blocks: 16329
  Show dependency tree
 
Reported: 2001-10-08 15:03 UTC by Jaroslav Tulach
Modified: 2008-12-22 23:19 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2001-10-08 15:03:22 UTC 
The javadoc of postWriteAccess says: "Run an action with write access as soon as
that is permitted." but a test that I have added into
test/unit/src/org/openide/util/MutexTest shows that it does not.

Please fix that behaviour and also apply the same for postReadAccess.

PS: the tests begin with Xtest not to break the test suite, delete the X when
you fix the problem.
Comment 1 anovak 2001-10-12 09:09:07 UTC 
I have taken a look at that. It seems to me that first "fail"s in both
tests are right. Mutex was written with that intention in mind. I have
a simple fix for that.

Second "fail"s are more problematic since I do not have fix for them,
in fact I think that I would need to rewrite some parts this very
critical class. So, I suggest to fix only first "fail"s and do not fix
the second. Maybe this is reasonable, since even though the requests
are run later, they see coherent state.
Comment 2 Jaroslav Tulach 2001-10-12 10:20:38 UTC 
Yes, the second fail is more problematic, but I guess that following
code:


// no MUTEX access around this code
MUTEX.readAccess () {
  MUTEX.postWriteAccess () {
	doSomething ();
  }
}
expectSomehtingIsDone ();

should behave in the same way as:

MUTEX.writeAccess () {
	MUTEX.readAccess () {
		MUTEX.postWriteAccess () {
			doSomething ();
		}
	}
	expectThatSomethingHasBeenDone ();
}

This might be crusial for Children.Keys that calls the setKeys in
MUTEX.postWriteAccess and it might happen that somebody asking for
writeAccess would not see modifications done by somebody else
immediatelly (as shown in the previous cases) which is probably wrong.
Comment 3 anovak 2001-10-15 12:34:43 UTC 
Basically, I fixed this bug so that the tests, plus bunch of others,
are passing now. Unfortunately, I saw this lock, likely caused by an
incosistent state of the Mutex:"OpenIDE Request Processor-0" daemon
prio=1 tid=0x1b0580 nid=0xd waiting on monitor [0xf2b81000..0xf2b819e0]
        at java.lang.Object.wait(Native Method)
        at org.openide.util.Mutex$QueueCell.sleep(Mutex.java:1145)
        at org.openide.util.Mutex.enter(Mutex.java:475)
        at org.openide.util.Mutex.postRequest(Mutex.java:853)
        at org.openide.util.Mutex.postWriteRequest(Mutex.java:368)
        at org.openide.nodes.Children$Keys.applyKeys(Children.java:1721)
        at org.openide.nodes.Children$Keys.setKeys(Children.java:1680)
        at
org.openide.loaders.FolderChildren.setKeys0(FolderChildren.java:229)
        at
org.openide.loaders.FolderChildren.access$300(FolderChildren.java:35)
        at
org.openide.loaders.FolderChildren$Addition.run(FolderChildren.java:375)
        at org.openide.util.Task.run(Task.java:152)
        at
org.openide.util.RequestProcessor$ProcessorThread.run(RequestProcessor.java:611)
Comment 4 anovak 2001-10-15 16:50:37 UTC 
Fixed in main trunk. I extended the tests as well.
Comment 5 Quality Engineering 2003-07-01 16:01:59 UTC 
Resolved for 3.4.x or earlier, no new info since then -> verified
Comment 6 Quality Engineering 2003-07-01 16:36:47 UTC 
Resolved for 3.4.x or earlier, no new info since then -> closing.