< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

RE: [reSIProcate] Exception encountered when using reSIProcate in a multi-threaded program


Title: Re: [reSIProcate] Exception encountered when using reSIProcate in a multi-threaded program

“We are using the time in ms xor thread id as the seed value. This just isn't
going
to cut it.”

 

I’m not sure I understand the issue with the current scheme – as long as you seed for each thread.  The thread id is used in the seed – so it should be unique – even if 2 threads seed in the same second.

 

Note:  Resip 0.9 does not contain the changes I made in the SVN head in order to ensure every windows thread is seeded correctly.  Resip 0.9 relies on the application calling random::init() if it is not using ThreadIf for threading.

 

Scott

 


From: Fischl jason [mailto:jason.fischl@xxxxxxxxx]
Sent: Monday, July 18, 2005 9:25 PM
To: Alan Hawrylyshen
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx; Andy Agarwal
Subject: Re: [reSIProcate] Exception encountered when using reSIProcate in a multi-threaded program

 

I think I got it. In win32, each thread needs to seed the rng. We are
using the time in ms xor thread id as the seed value. This just isn't
going to cut it. I'm going to try changing it to use GetTickCount
instead of Timer::getTimeMs. Also, going to change some other things
in the seed value.

More specifically:

Data buffer;
DataStream strm(buffer);
strm << GetTickCount() << ":"
strm << GetCurrentProcessId() << ":";
strm << GetCurrentThreadId();
strm.flush();
unsigned int seed = buffer.hash();




On 7/18/05, Alan Hawrylyshen <alan@xxxxxxxxxx> wrote:
>
> On Jul 18, 2005, at 17.38, Fischl jason wrote:
>
> >
> > You may also need to put debug in Random::getRandomHex. Possibly we're
> > getting nailed on some win32 thread safety issue with getRandom. Focus
> > your effort there.
> >
>
>
> It just dawned on me that this behavior can arise when (if) the
> random number generator is initialized repeatedly.
> If the seed it timebased and your call resolution is smaller than the
> clock resolution, you will get duplicates.
>
> Alan
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel