RE: [reSIProcate] Exception encountered when using reSIProcate in a multi-threaded program
Yeah i was using resip 0.9 which did not have per thread seeding. I
tried rev. 5096 (before Jason's changes) and could not repro my problem
anymore. Of course, the problem also does not show up with the latest
resip version.
Thanks for all your help in this.
andy
________________________________
From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
Sent: Tuesday, July 19, 2005 5:06 AM
To: jason@xxxxxx; 'Alan Hawrylyshen'
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx; Andy Agarwal
Subject: 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