-------------BEGINNING OF IR---------------- VHDL Issue Number: 2109 Language_Version VHDL-2002 Classification Language Modeling Enhancement or Deficiency Summary Inter-process communication can hang unnecessarily Relevant_LRM_Sections Related_Issues Key_Words_and_Phrases protected type, process, wait Authors_Name Paul Butler Authors_Phone_Number (512) 683-8743 Authors_Fax_Number Authors_Email_Address Paul.Butler@ni.com Authors_Affiliation National Instruments Authors_Address1 11500 N. Mopac Authors_Address2 Austin, TX 78759 Authors_Address3 Current Status: Forwarded Superseded By: ------------------------ Date Submitted: 1 February 2007 Date Analyzed: 01 February 2007 Author of Analysis: Chuck Swart(including comments from Peter Ashenden) Revision Number: 1 Date Last Revised: 01 February 2007 Description of Problem ---------------------- Two processes that each loop (without passing time or deltas) while waiting for progress in the other process might iterate forever if the simulator doesn't execute code in both processes. At least one popular simulator chooses one process and executes only the code in that process until it executes a statement that passes time (or a delta), causing the code below to never complete. If the LRM requires that simulator behavior, protected types seem unnecessary. If the LRM required some form of preemption between simultaneous processes, VHDL users could rely on their inter-process communication to complete. As it is, I can force a kind of cooperative preemption by passing time in both loops. Since protected type methods cannot pass time, I can't build that behavior into my semaphore type. Even if both processes execute, the looping wait looks inefficient. The ability to wait on something other than signals might help the situation. entity ThreadLock is end entity ThreadLock; architecture behave of ThreadLock is type Semaphore is protected impure function try_get return boolean; procedure put; end protected; type Semaphore is protected body variable available : boolean :: true; impure function try_get return boolean is variable rval : boolean; begin rval := available; available := false; return rval; end function try_get; procedure put is begin available := true; end procedure put; end protected body; shared variable SemA, SemB : Semaphore; begin P1: process is begin assert SemA.try_get; wait for 0 ns; SemA.put; while not SemB.try_get loop report "P1 waiting for SemB"; -- wait for 0 ns; end loop; report "P1 finished"; wait; end process P1; P2: process is begin assert SemB.try_get; wait for 0 ns; SemB.put; while not SemA.try_get loop report "P2 waiting for SemA"; -- wait for 0 ns; end loop; report "P2 finished"; wait; end process P2; end behave; Execution works this way: P1 gets SemA and waits for 0 ns, P2 gets SemB and waits for 0 ns. In delta 1, execution resumes when both of the processes puts its semaphore and loops while waiting for the other process to put its semaphore. If both processes execute in delta 1, both processes will finish. If execution follows only one process until it passes time, neither process will finish. Uncommenting the "wait for 0 ns" lines will allow the processes to finish. Proposed Resolution ------------------- VASG-ISAC Analysis & Rationale ------------------------------ Protected types were added to VHDL to deal with mutual exclusion on access to shared data. IPC was specifically not addressed. The submitter is correct: single processor implementations which do not "time-slice" between VHDL processes will give different results from multiple processor simulations or time-slice single processor simulations. Both implementations are correct under current LRM semantics. This IR relates to the issues of channels and interfaces that are being canvassed in the VHDL-TC. The submitter is looking to use protected types for a form of interprocess communication (IPC). There are a whole bunch of different IPC mechanisms, such as semaphores of different flavours and FIFOs queues, that embody both abstract communication and synchronization. The synchronization aspects involve waiting on one one or more conditions. This area has been well explored and reported in the literature on concurrent programming and operating systems. The protected type mechanism that was included in VHDL-2000 was based on Hoare monitors, but it only included the aspect of mutual exclusion on method entry. Hoare monitors also involve declaring condition variables on which a monitor can wait. While waiting, the caller relinquishes mutex, allowing another monitor call to proceed. That call can affect state to make the condition true, thus re-enabling the suspended caller. Assuming a lot of semantics, the submitter's semaphore type could be expressed as type boolean_semaphore is protected procedure lock; procedure free; end protected boolean_semaphore; type boolean_semaphore is protected body variable available : boolean := true; procedure lock is begin while not available loop wait until available; available := false; end procedure lock; procedure free is begin available := true; end procedure free; end protected body boolean_semaphore; This general issue needs a lot of requirements analysis, especially as it relates to transaction-level modeling. Consequently, this will be forwarded to the VHDL-TC Requirements-SC. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Forward as a requirement for future language revisions. -------------END OF IR----------------