develooper Front page | perl.ithreads | Postings from August 2002

Re: Thread-Tie-0.01

Thread Previous | Thread Next
From:
Elizabeth Mattijsen
Date:
August 12, 2002 03:19
Subject:
Re: Thread-Tie-0.01
Message ID:
4.2.0.58.20020812120154.03adab00@mickey.dijkmat.nl
At 10:45 AM 8/12/02 +0100, Nick Ing-Simmons wrote:
> >Maybe it is from a CPU point of view, but it definitely isn't from a memory
> >point of view.  Because now in an array each element will need to be tied
> >to the shared magic.
>It isn't quite that bad. When you do a FETCH the returned value gets
>tie - it should be freed when all references to the FETCHed value
>go out of scope.

I'm not sure I'm following you here...  Could you elaborate?


> >In my approach only the object to which the array is
> >tied, contains shared elements.  Inside the thread, the array is an array
> >just like any other array.  Which saves a lot on magic.  Or am I mistaken
> >in this?
>As far as I can tell your approach and the one I was aiming at are
>identical (aside from the showdow thread thing).
>However as I am doing all the tie and FETCH/STORE etc. in XS code
>it is easier to make mistakes.

It's easy to make mistakes with this in Perl also, I can tell you...  ;-)

Problem is that something may be working as you think it should for a 
_long_ time before you realise there is a basic flaw in it.  It think the 
recently discovered behaviour of {,N} in regexps is a nice example of 
that...  ;-)


> >> >=item memory usage
> >> >Shared variables in this approach are truly shared.  The value of a 
> variable
> >> >only exists once in memory.  This implementation also circumvents the 
> memory
> >> >leak that currently (threads::shared version 0.90) plagues any shared 
> array
> >> >or shared hash access.
> >>As the threads::shared scheme is _supposed_ to be exactly as you describe
> >>there _should_ be no difference here.
> >Apart from the huge memory leak that makes it impossible to use shared
> >arrays and hashes in a production environment.
>So let us find it.

As far as I can tell, it doesn't happen when you're just FETCHing and 
STOREing in arrays or hashes, but it happens if you add or remove elements 
(such as in shift, unshift, push and pop, and adding or delete()ing keys 
from hashes), e.g.

   $ perl -Mthreads -Mthreads::shared -e 'my @array : shared; while (1) { 
push( @array,1 ); pop( @array ) }'

will start eating away at your memory quite rigorously...  ;-)

I'm not 100% sure with hashes, that may need involvement of multiple 
threads.  Couldn't reproduce it as simply as above...

As most of it is in XS, I won't be able to help you much there...


> >- threads->yield doesn't seem to yield.
> >This means you're burning CPU needlessly until your timeslice is over.
>ick - can we find something that _does_ yield?

You mean an OS that yields()?  The thing is that using shared variables 
_doesn't_ eat away at CPU as my approach does.  Maybe that is caused by the 
client/server swap you (or Arthur?) were describing...


> >You will see that the client thread is able to gain the lock again after a
> >cond_signal (about 75% of the time, under Linux, on my development box)
> >before the server thread receives the signal.
>You normally need a pair of semaphores to exchange requests between
>a client and a server

I realise that.  What I do is that I have a control and a data 
"channel".  Control channel going undef means data is ready for the client 
to be fetched.  Data channel going undef means that data is fetched by 
client.  I assume you're referring to that?


>  - but note that a "condition variable" is NOT
>quite the same as a semaphore. Which is why higher level things like
>queues are so popular.

Quite.




Liz


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About