Appeal No. 2004-2187
Application No. 09/378,549
of lock into a storage area corresponding to said object, in
a state where a plurality of threads exist, said method
comprising the steps of:
if a first thread attempts to acquire a lock of an
object that has been acquired by a second thread,
determining whether said bit representing the type of the
lock of said object represents said first type of lock; and
if said bit represents said first type of lock, setting
a contention bit.
THE REFERENCE
Bacon 6,247,025 Jun. 12, 2001
(filed Sep. 22, 1997)
THE REJECTION
Claims 1-14 stand rejected under 35 U.S.C. § 102(e) as being
anticipated by Bacon.
OPINION
We reverse the aforementioned rejection. We need to address
only the independent claims, i.e., claims 1, 6, 9, 10 and 12-14.
Claims 1, 6, 9 and 12-14 require storing a bit representing
a type of a lock that locks an object, and claim 10 requires a
type identifier associated with a lock that locks an object.
The examiner argues (answer, page 6):
The “Bacon bit” as is used in Bacon is held at “0" when
an object [sic, a thread] has an exclusive lock on an
object and [the lock] does not have any threads (tasks
of an operating system) waiting to gain the lock on the
object. The “Bacon bit” is “inflated” (i.e.[,] changed
from “0" to “1") when a thread tries to obtain a lock
2
Page: Previous 1 2 3 4 5 Next
Last modified: November 3, 2007