Re: [Gems-users] Tourmaline and scheduling

[Derek Hower <drh5@xxxxxxxxxxx>]

Reply from Dan Gibson:


Tourmaline is a functional transactional memory simulator, which is  
intended to have extensible behavior for future expansion. Its  
default behavior makes no attempt to model a realistic timing nor  
interleaving of transactions -- it simply provides the bare minimum  
implentation of atomicity in the most trivial, simulator-magic way  
possible -- by literally disabling all (other) processors.
To my knowledge, the released version of tourmaline has never been  
used to collect viable research data -- it is a tool intended to  
enable warm-up of transactional applications, as well as to  
facilitate debugging of transactional applications seperate from the  
debugging of the timing simulator.
If you are interested in looking at running concurrent threads, you  
should look into implementing sub-classes of TransactionController,  
which Tourmaline uses to guarantee atomicity of transactions. There  
is a how-to guide in the README for tourmaline, called the  
'Transaction Controller Cookbook'.
Please note that the /timing/ runs for the LogTM family of work all  
used Ruby, not Tourmaline. However, tourmaline is a viable tool for  
(much) longer simulations at the cost of some timing fidelity.
Regards,
Dan


On Sep 28, 2007, at 3:37 AM, horsnelm@xxxxxxxxxxxx wrote:

> Hi,
>
> I've been looking at the code inside the tourmaline TM module of  
> the gems
> package. I'm trying to run some benchmarks, in particular the  
> stamp-0.9.4
> benchmarks, and wondered if you could comment on the scheduling  
> policy and
> how you have used tourmaline, or gems in general, to generate your
> results.
>
> I can see in the tourmaline code, that when you begin a transaction  
> you
> disable interrupts in the processor registers, which means that  
> until the
> transaction resolves it cannot be interrupted. You switch back on
> interrupts when the transaction commits or aborts.
>
> Is it not the case that the operating system threads will  
> interleave with
> the transactions, competing for the cpu time? Do you prevent this from
> happening by changing the scheduling policy in the OS, or do you  
> measure
> your results in some other manner? The reason I ask, is that when  
> running
> say a 4 threaded application, on a 4 cpu architecture, transactions
> infrequently overlap as they are scheduled according to the OS.  
> Ideally
> I'd like the transactional threads to run as concurrently as  
> possible to
> look at the interactions between them.
>
> Thanks,
>
> Matt Horsnell
> _______________________________________________
> 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.