mersenneforum.org mtsieve
 Register FAQ Search Today's Posts Mark Forums Read

2020-01-20, 08:41   #287
unconnected

May 2009
Russia, Moscow

3×19×43 Posts

Quote:
 Originally Posted by rogue Since you are building on your own, you can comment out the code in the SharedMemoryItem.cpp class in the TryLock(), Lock(), and Release() methods and rebuild. This will only work if you have 1 worker. If you have any debugging experience, a stack trace would be helpful.
Mark, I've added debug printf to Lock() and found that in case of error return code is 35 (EDEADLK):

Code:
The pthread_mutex_lock() function may fail if:
EDEADLK The current thread already owns the mutex.
Commenting methods didn't help - source successfully compiled and ran but no sieve at all, only removed algebraic factors.

2020-01-20, 10:01   #288
Happy5214

"Alexander"
Nov 2008
The Alamo City

5358 Posts

Quote:
 Originally Posted by unconnected Mark, I've added debug printf to Lock() and found that in case of error return code is 35 (EDEADLK): Code: The pthread_mutex_lock() function may fail if: EDEADLK The current thread already owns the mutex. Commenting methods didn't help - source successfully compiled and ran but no sieve at all, only removed algebraic factors.
The offending code appears to be core/Worker.cpp, lines 164-167:
Code:
   SetHasWorkToDo();

//
ip_WorkerStatus->Release();
The lock is being released after the worker status is changed, so the first method ends up re-locking the mutex. Flipping the two commands fixed the error for me.

2020-01-21, 01:29   #289
rogue

"Mark"
Apr 2003
Between here and the

16DA16 Posts

Quote:
 Originally Posted by Happy5214 The offending code appears to be core/Worker.cpp, lines 164-167: Code:  SetHasWorkToDo(); // ip_WorkerStatus->Release(); The lock is being released after the worker status is changed, so the first method ends up re-locking the mutex. Flipping the two commands fixed the error for me.
Great catch, but the proper fix is to modify Worker.h. SetHasWorkToDo() should call ip_WorkerStatus->SetValueHaveLock(). This is because the method is called when the thread already has a lock on the ip_WorkerStatus object. This method releases that lock after it has built the collection of primes for the thread.

I wonder why Windows doesn't catch this.

2020-01-21, 07:08   #290
Happy5214

"Alexander"
Nov 2008
The Alamo City

34910 Posts

Quote:
 Originally Posted by rogue Great catch, but the proper fix is to modify Worker.h. SetHasWorkToDo() should call ip_WorkerStatus->SetValueHaveLock(). This is because the method is called when the thread already has a lock on the ip_WorkerStatus object. This method releases that lock after it has built the collection of primes for the thread. I wonder why Windows doesn't catch this.
From the Microsoft documentation on EnterCriticalSection:

Quote:
 After a thread has ownership of a critical section, it can make additional calls to EnterCriticalSection or TryEnterCriticalSection without blocking its execution. This prevents a thread from deadlocking itself while waiting for a critical section that it already owns. The thread enters the critical section each time EnterCriticalSection and TryEnterCriticalSection succeed. A thread must call LeaveCriticalSection once for each time that it entered the critical section.
I take this to mean that repeated calls don't result in an error, unlike pthreads.

Last fiddled with by Happy5214 on 2020-01-21 at 07:09

2020-01-21, 14:05   #291
rogue

"Mark"
Apr 2003
Between here and the

2·32·52·13 Posts

Quote:
 Originally Posted by Happy5214 From the Microsoft documentation on EnterCriticalSection: I take this to mean that repeated calls don't result in an error, unlike pthreads.
Yet another reason to dislike Windows. Thanks for finding the reason.

 2020-02-10, 02:32 #292 Dylan14     "Dylan" Mar 2017 499 Posts A suggestion: when using the -A (or the --applyandexit flag), assume that if there is no file given with -I, assume that the factors are given in a file called "factors.txt", or warn the user that the switch requires a file name to be given with -I to work.
2020-02-10, 12:30   #293
rogue

"Mark"
Apr 2003
Between here and the

2·32·52·13 Posts

Quote:
 Originally Posted by Dylan14 A suggestion: when using the -A (or the --applyandexit flag), assume that if there is no file given with -I, assume that the factors are given in a file called "factors.txt", or warn the user that the switch requires a file name to be given with -I to work.
Seems reasonable

 2020-04-12, 23:09 #294 rogue     "Mark" Apr 2003 Between here and the 16DA16 Posts I posted 1.9.6. I was sitting on it for a while as I forgot to post. Here are the changes: Fixed issue in srsieve2 where it crashes when starting a new sieve. Fixed issue in srsieve2 where it finds an invalid factor and terminates. Refactored logic for "single worker" and "rebuild" logic so they work more nicely together. Fixed calculation of p/sec which is wrong after workers are recreated. Feset factor stats whenever workers are created as the rate is inflated for lower p as far more terms are removed. Fix issue with multiple threads which can cause program to hang. Add support for ABC format to srsieve2.
 2020-04-18, 12:20 #295 JeppeSN     "Jeppe" Jan 2016 Denmark 2168 Posts Silly question: Which is the preferred place to download from if I only care about the Windows (x64) binaries, not the source? On https://www.mersenneforum.org/rogue/mtsieve.html there is a file with 1.9.6 in its name. The version history on that html page does not go further than 1.7.3. On https://sourceforge.net/projects/mtsieve/ there is a file with 1.9.7 in its name. Does it include both source and binaries? Is this a "beta" or "unreleased" version? The README_MTSieve.txt file refers to the former of these two web sites. /JeppeSN
2020-04-18, 15:00   #296
rogue

"Mark"
Apr 2003
Between here and the

2×32×52×13 Posts

Quote:
 Originally Posted by JeppeSN Silly question: Which is the preferred place to download from if I only care about the Windows (x64) binaries, not the source? On https://www.mersenneforum.org/rogue/mtsieve.html there is a file with 1.9.6 in its name. The version history on that html page does not go further than 1.7.3. On https://sourceforge.net/projects/mtsieve/ there is a file with 1.9.7 in its name. Does it include both source and binaries? Is this a "beta" or "unreleased" version? The README_MTSieve.txt file refers to the former of these two web sites. /JeppeSN
Sorry about the confusion. 1.9.6 and 1.9.7 are the same. I misnamed it because the version in the changes.txt file was incorrect. The file is named incorrectly on the one webpage. I need to change that to point to sourceforge.

 2020-05-03, 23:26 #297 pepi37     Dec 2011 After milion nines:) 22×3×109 Posts I have found small error ( if we can call it error) In latest twinsieve release if we set -P 10000000 it only sieve up to 10007. I believe it has some connection with chunks ( number of worker or so) So that is nearly cosmetic error. On higher P limit everything is OK Can you also add in info line cpu usage in percentage? Last fiddled with by pepi37 on 2020-05-03 at 23:33