|
store number 0 to text file before execution of ur application.During execution get that number from the file.Increment that nos. by 1.and overrite it to same file.![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
Regards
Chintan
www.visharadsoft.com
(Nothing is so purify as KNOWLEDGE)
|
|
|
|
|
Tried it already...
This is too much I/O at this rate I would generate between 30-50 per sec.
I want 50,000 per sec.
|
|
|
|
|
It's very difficult to maintain state across application crashes without resorting to some form of external mechanism in which to persist that state (IO/Database/WebService/Whatever). However, have you considered the use of GUIDS in your application?
"It was the day before today.... I remember it like it was yesterday."
-Moleman
|
|
|
|
|
The problem with saving something to disk or database is the reduction in performance of the application.
I have to generate the numbers as fast as 50,000 per second. Without loss.
I have tried saving in registry, database and files, the i/o overhead is too much. I didn't forget MSMQ too.
And converting GUID to Long does not guarantee uniqueness.
Please help with something else.
|
|
|
|
|
I'm intrigued - what does your application do that it requires 50,000 unique numbers every second?
"It was the day before today.... I remember it like it was yesterday."
-Moleman
|
|
|
|
|
Well, actually other apps request mine to give them a unique number. and those request come very very fast...
|
|
|
|
|
Ah, I see.
Here's an idea (but I think Luc's is better, now that I've just read it). The major problem you're facing is the IO overhead, and yet you do need some way to prevent duplicates from occuring.
How about booking out blocks of numbers in large chunks (for the sake of argument, say 50,000 at a time), and keeping a file which tells your program the range of the next chunk. That way, if your program crashed it could restart and know what the next chunk of numbers should be, and the number of IO requests would be fewer than with an update after every number issued. Of course, in a situation where your program crashed after only 10 numbers had been issued, you'd have "lost" 49,990 numbers...
"It was the day before today.... I remember it like it was yesterday."
-Moleman
|
|
|
|
|
Hi,
this is how I might tackle this one:
- split the (32-bit) number you are after into a session field and a sequential field
(e.g. 16-bit each).
- keep the session field in a file, read it from file, increment it, write it back to file,
read it again from file, check it, now trust it;
- withtin the session, that just got a new session ID, initialize the sequential field
to zero, increment it everytime you need a new number
- if sequential field is exhausted, start a new session
- use Interlocked.Increment to protect your sequential field
- use appropriate locking to protect your operations on the session ID.
You can choose how many bits you spend to the session ID; more bits means less numbers
get skipped (new session starts with skipping some) but more session ID operations
(i.e. file operations) are involved.
|
|
|
|
|
I think it is a very good approach.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
That sounds pretty smart, my 5!
|
|
|
|
|
You could always use the DateTime.Ticks - with a little bit of synchronisation to make sure that you haven't already retrieved it.
private static object SyncLock = new object();
private long lastValue = 0;
public static long GetUnique()
{
lock (SyncLock)
{
long value = lastValue;
while (value == lastValue)
{
value = DateTime.Ticks;
}
lastValue = value;
return value;
}
}That's off the top of my head, so I apologise now if it needs tweaking a little bit.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Devise a hashing algorithm for a snowflake. Shave ice as needed. 
|
|
|
|
|
The problem is,
my application gets more requests that ticks can generate.
plus what if someone were to reset the system clock. It would then give duplicate numbers.
|
|
|
|
|
You're right about the system clock, but really how often does that happen?
So, you get requests faster than 100 nanoseconds. How often does this happen? If you notice, the code I presented makes sure that you get a new value just by comparing the lastvalue to the selected DateTime.Ticks and loops until you've got a new one.
Remember that the DateTime.Ticks property represents the number of 100-nanosecond intervals since 1 Jan 0001.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
You're cripling his app with a busy loop !
And worst of all, adding more and faster CPUs wont help him in future.
|
|
|
|
|
ROTFL.
I did consider using a Sleep for 99 nanoseconds
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
What if the system clock was reset...
|
|
|
|
|
If you are using this in a production environment, the question is - when do you reset the system clock? In over 20 years of professional development, I can't think of a single time where the system clock needed to be reset - and bear in mind that I've done a lot of work with real-time monitoring systems where the system clock played a large part in monitoring/managing systems.
If you're that paranoid about the system clock, go with Luc's idea. It doesn't bother me as long as you get a system that you are happy with. That's all that matters.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Is it too late to change the requirements to return a GUID instead of an integer. Then you wouldn't have to worry a bout all of this crazy stuff...
One more idea, does the number have to be an integer... There is probably a faster way to do this, but it'll do more than 50,000 in a second from my test. Get the current ticks, then append an incrementing decimal to it.
private int currentRequest = 0;
private long uniqueNumber = System.DateTime.Now.Ticks;
public decimal GetUniqueNumber
{
get
{
return Convert.ToDecimal(uniqueNumber.ToString() + "." + newNumber.ToString());
}
}
Hogan
|
|
|
|
|
Hello,
I programmed my solution with the Environment.GetCommandLineArgs(); to get the arguments.
When i use the CMD command "path_to_exe/solution.exe file.ing", then it will work fine, my program strats up and opens the file.
Now i added the .ing extension to the registery and added the open command "path_to_exe/solution.exe %1". When i double click on a .ing file then i get error screen (the windows send report screen). What am i doing wrong?
please help!
|
|
|
|
|
'ing' is not recognize by window as extension.Window can understand extension which it knows.e.g bmp is extension for bitmap file.you can give bpm for bitmap.
Regards
Chintan
www.visharadsoft.com
(Nothing is so purify as KNOWLEDGE)
|
|
|
|
|
Thats right, but im insert the .ing in te registery (HK_CLASS_ROOT). that way windows will recognize the .ing and give it the icon what i want.
|
|
|
|
|
Add some logging code in there to see when the program dies -- in particular print out the command arguments to make sure you're getting the correct file name in the format that you're expecting.
|
|
|
|
|
The first thing my program does is geting the args then display it with a messagebox. but the message box never shows up. the program doesn't even show up, i get only the error page from windows 
public Form1()<br />
{<br />
InitializeComponent();<br />
<br />
string[] args = Environment.GetCommandLineArgs();<br />
MessageBox.Show("args length: " + args.Length.ToString());<br />
<br />
|
|
|
|
|
1 - Change the command to "path_to_exe/solution.exe" "%1"
2 - Check that the .ing extension default value matches the registry entry that contains the open command.
Deja View - the feeling that you've seen this post before.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
