Multithreading code issues - increment to volatile int/long aren't atomic - increments could be lost

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Won't Fix
• Affects Version/s: 6.2.0 CE M2
• Fix Version/s: --Sprint 11/12, 6.2.0 CE M2
• Component/s: WCM
• Labels:
  • bugsquad
  • community-verifier
• Environment: Mac OSX 10.7.3, Tomcat 6, Oracle Java EA 7u4 Mac, Apache Derby 10.8
• Similar Issues: Show 5 results ; ;

  LPS-9506	Alter Counter increment to be atomic and maintain transaction safety
  LPS-20318	Social Equity SUBSCRIPTION increment on message boards not working
  LPS-4508	WCM Display - Ability to disable the 'view count' increment
  LPS-8759	Document Library Versions are incrementing incorrectly
  LPS-3467	PortalImpl has multithreading synchornization issues on portal port (Integer)

Bug:
1) Increment of volatile field com.liferay.portal.kernel.concurrent.ThreadPoolExecutor$WorkerTask._localCompletedTaskCount in com.liferay.portal.kernel.concurrent.ThreadPoolExecutor$WorkerTask._runTask(Runnable)
2) Increment of volatile field com.liferay.portal.search.lucene.IndexAccessorImpl._batchCount in com.liferay.portal.search.lucene.IndexAccessorImpl._write(Term, Document)
3) Increment of volatile field com.liferay.portal.search.lucene.IndexAccessorImpl._batchCount in com.liferay.portal.search.lucene.IndexAccessorImpl.deleteDocuments(Term)

code increments a volatile field. Increments of volatile fields aren't atomic. If more than one thread is incrementing the field at the same time, increments could be lost.

[Juan Fernández]

According to Shuyang Zhou "There are reasons that we are using volatile fields over Atomic fields for certain cases.

The ThreadPoolExecutor.java change is totally unnecessary, because the mainLock ensures mutually exclusive accessing already, we only need volatile to ensure memory visibility across threads.

The IndexAccessorImpl.java change is also unneeded, we can tolerate loss update for batch indexing, so volatile provides better performance."

So I'm closing this ticket.
Anyways, thanks a lot for your contribution. Keep your suggestions comming.
Juan Fernández

[Michael Saechang]

Closing as per Juan's comment.