« Return to Thread: 'not' as atomic symbol

Re: message queue put-back and backtracking

by Samer Abdallah :: Rate this Message:

On 12 Jan 2007, at 16:27, Jan Wielemaker wrote:

> Samer,
>
> On Friday 12 January 2007 15:26, Samer Abdallah wrote:
>> Would it be much trouble to add a
>> thread_putback_message(Queue,Term) procedure
>> which pushes Term onto the head of the queue?
>> Even better would be a backtrackable version of
>> thread_get_message/2 which pushes back the term it just
>> read on backtracking. (If this seems like an odd request,
>> I can explain what I'm trying to do - just thought I'd
>> keep my initial post short and to-the-point.)
>
> The analogy for message queus is more like a reading/writing to a
> pipe,
> containing terms rather than characters. I'm not saying this can't be
> done, but given the possibility of access from multiple threads,
> strange
> things can happen.

I see what you mean. In that case the solution you propose below
would be ok - provide a method to send a message to the head
of the queue and leave us the option to construct a backtrackable
get_message to use in restricted cases (such as my own) where it is
known to be safe.

>
> Another disadvantage is that it makes thread_get_message
> non-deterministic. Somewhat more in line with the desing might be
> a thread_send_message that puts the new message at the head rather
> than at the tail. That allows for a design like:
>
> ndet_get_message(Queue, Message) :-
> thread_get_message(Queue, Message),
> ( true
> ; thread_send_message(Queue, Message, [at(head)]),
> fail
> ).
>
> Note however that this implementation is not correct with respect
> to the
> cut.

I'm not sure I understand what you mean.

>
> So, I'd prefer to consider the problem at a somewhat higher level
> first
> to see whether there is an elegant solution you missed there.
Well, I would like to be able to solve the problem without invoking
another thread - essentially what I want is a findall that returns
a *lazy* list that carries enough information about the state of
solution search to build itself on demand as it goes along. I can't
see how to do it without using a meta-interpreter which handles
the search tree explicitly at the meta level.
My current transaction logic interpreter still relies on backtracking
in the underlying interpreter - doing otherwise would make it much
more complex. Hence the quick and i hope not-too-dirty multithreading
approach.

Thanks,
Samer

>
> Cheers --- Jan
>
>
> ------------
> For further info, please visit http://www.swi-prolog.org/
>
> To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-
> mail>"
> in its body to majordomo@...

------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

« Return to Thread: 'not' as atomic symbol

LightInTheBox - Buy quality products at wholesale price