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

Fergus Henderson fjh at cs.mu.OZ.AU
Tue Nov 19 15:39:30 AEDT 2002


On 18-Nov-2002, Julian Fondren <cleverjulian at hotmail.com> wrote:
> ------------------------------------------------------------------------
> No directory access, no concurrency (though I see allusions to an
> experimental multithreaded Mercury: does it use OS threads or something
> lighter?  How can I experiment with it?), no networking -- but the
> first and the last seem potentially well-covered by the foreign language
> access.
> 
> Does anyone have a directory-stream/networking library handy?  If not,
> how can I contribute mine when I finish them?  Is anyone thinking about
> Erlang/Concurrent-Haskell -style concurrency (with independent
> lightweight processes and message-passing, as opposed to evil Posix
> threads with mutexes and semaphores)?

What exactly is evil about Posix threads?

Others have already mentioned the libraries in the mercury-extras distribution.

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

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

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.

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

> Also, is there a 'remove line terminator' in the library that I don't
> see?  If not, how does anyone get io__read_line_as_string (which
> returns a string with a newline) to string__to_int ?  I've written

You can use string__remove_suffix.
For example:

	:- import_module io, string, exception.
	main -->
		io__read_line_as_string(Res),
		(
			{ Res = ok(Line) },
			{ string__remove_suffix(Line, "\n", String) },
			{ string__to_int(String, Int) }
		->
			print("you entered: "), print(Int), nl
		;
			{ throw("I/O error, invalid entry or eof") }
		).


References

[1] "Towards parallel Mercury".
    Thomas Conway. Ph.D. thesis, Department of Computer Science and Software
    Engineering, The University of Melbourne, July 2002.
<http://www.cs.mu.oz.au/research/mercury/information/papers.html#conway-thesis>

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------



More information about the users mailing list