summaryrefslogtreecommitdiffstats
path: root/base/lock_impl_win.cc
Commit message (Collapse)AuthorAgeFilesLines
* Test was examining a variable without first acquiring a required Lock.ralphl@chromium.org2009-03-191-1/+1
| | | | | | | Also changed Lock::AssertAcquired to be const function (it already was const, in practice, just not declared that way). Review URL: http://codereview.chromium.org/42402 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12157 0039d316-1c4b-4281-b951-d872f2087c98
* Added a debug method AssertAcquired() that compiles to nothing in non-debug ↵ralphl@chromium.org2009-03-181-0/+15
| | | | | | | | | | | | | | | | | builds. In debug builds, the method will DCHECK if the current thread does not hold the lock. I also removed a class that was not being used (AutoLockImpl) which seems like someone just copied the Lock.h file and blindly added an Impl for the AutoLock class. Thre are places in my code where I want to use the AutoUnlock class. I can't see why it was restricted to use by the condition variable class only, so I just made it into a regular class with no restrictions. I noticed that JamesR posted a CL about a month ago that made AutoUnlock a public class, but it was never committed, so I added him to this CL for review too. Review URL: http://codereview.chromium.org/48109 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12037 0039d316-1c4b-4281-b951-d872f2087c98
* Move windows specific lock-recursion-counter into windows impl filejar@google.com2008-10-211-2/+32
| | | | | | | | | | | | | | | | | | | | Unix implementation of lock leaks the underlying lock_impl_ member so that the condition variable implementation can directly acquire and release the lock (without going through our abstract interface). This causse the recursion counter to become incorrect on such platforms. Windows uses an implementation of condition variables that uses our abstract interface, and hence is the only implementation that can track the recursion count (and besides... windows is the only platform that currently allows recursive (multiple) acquisitions of a lock by a single thread. I'll work on gracefully removing the depricated lock.cc after I've landed this change. r=cpu Review URL: http://codereview.chromium.org/7660 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3703 0039d316-1c4b-4281-b951-d872f2087c98
* Use a more compact license header in source files.license.bot2008-08-241-28/+4
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
* Add a spinlock wait to the dearly beloved crititcal sectioncpu@google.com2008-08-231-1/+3
| | | | | | | | - the 2000 is a guess, I think the right number is between 1000 and 4000 - lets look at perf, if hurts then we remove it git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1271 0039d316-1c4b-4281-b951-d872f2087c98
* Port LockImpl, Lock, and ConditionVariable to pthreads-supporting platforms.mmentovai@google.com2008-08-081-5/+5
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@567 0039d316-1c4b-4281-b951-d872f2087c98
* Add base to the repository.initial.commit2008-07-261-0/+50
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-15 17:52:57 +0000