[mercury-users] Style, Newbie decision question, "What? No X?!", Microbenchmark

[Julian Fondren]

>What exactly is evil about Posix threads?

Emotionally, I percieve them as automatically pervasive -- but on
closer inspection it seems that my main irritation has more to do with
imperative programming than Posix threads, so I retract my assertion
that they 'are evil'.  Posix threads help when a system with its own
concurrency wants to access a foreign function that may block, and as
an internal optimization for multiple CPU systems.  (I also understand
that some people suggest the use of Posix threads in poorly-designed
GUi applications.)

>Mercury has several mechanisms for parallelism and concurrency.
>These are still listed in the "work in progress" section,
>mainly because they aren't properly documented.
>
>For parallelism, there is independent and-parallelism.  For concurrency,
>the is the extras/concurrency library, which is implemented in different
>ways, depending on which back-end and grade of the Mercury compiler you 
>use:
>
>	(a) for the low-level back-end, Mercury threads are mapped to
>	    "contexts" (the Mercury implementation's name for our lightweight
>	    user-level threads), which can be scheduled either
>	    (i) using non-preemptive scheduling (the asm_fast.gc grade) or
>	    (ii) by multiplexing contexts over several Posix threads
>	         (the asm_fast.gc.par grade), which will then execute
>		 using the operating system's preemptive scheduling;
>		 threads may thus run in parallel on multi-CPU machines

Oh, nifty.

>	(b) for the high-level back-end, each Mercury thread is mapped
>	    to its own Posix thread (the hlc.gc.par grade)

Thanks for the warning, I'll try to avoid this grade until it matures.
(Or is the use of Posix threads a fundamental limitation?)

>The synchronization primitives provided are "mvars", which encapsulate
>mutual exclusion and mutable state (they are very similar to the Haskell
>construct of the same name); "channels", which are unbounded buffers
>that can be used for message passing; and semaphores.

OK.

>For more information on concurrency and parallelism in Mercury,
>see Tom Conway's PhD thesis [1].

Thanks for the reference -- I had thought the paper only on
parallelism.


_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------