Re: [Gems-users] Assertion Failed in GEMS1.4

[Enrique Vallejo Gutierrez <enrique@xxxxxxxxxxxxx>]

Hi James,

	A new code block in delayRestart() in GEMS 1.4 checks that there is
no deadlock in the system. However, it does not consider the
m_max_waiting_ts members of the remote TransactionManagers, so it can
trigger a false positive in the asssert. The simplest way to fix this is to
remove the new block (you will know if you have a deadlock...).

	Another solution is to remove the whole delayRestart function (by
returning always false). This removes the local congestion control in the
Transaction Manager, but leads to a more realistic simulation of the system
(given that this congestion control makes use of global pointers to access
data in remote processors to stop the local processor).

Regards,

Enrique Vallejo
University of Cantabria, Spain
http://www.atc.unican.es/~enrique/


-----Mensaje original-----
De: gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-bounces@xxxxxxxxxxx]
En nombre de James Wang
Enviado el: domingo, 20 de mayo de 2007 0:06
Para: Gems Users
Asunto: [Gems-users] Assertion Failed in GEMS1.4

Hi All:
    I have made a customized transactional memory protocol. The same deque
benchmark works fine on GEMS1.3 but  fails an assertion in GEMS1.4. The
assertion seems to be in TransactionManager::delayRestart()         ASSERT(p
!= getID()); // DEADLOCK! 
    Any idea what it means? Thanks in advance for any reply.
 
Regards
James




_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding
"site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.