Click here to Skip to main content

Pablo Aliskevicius - Professional Profile

@PabloAliskevicius

Summary

14,151
Author
4,731
Authority
897
Debator
62
Editor
40
Enquirer
687
Organiser
1,895
Participant
Pablo writes code for a living, in C++, C#, and SQL.
 
To make all that work easier, he uses some C++ libraries: STL, ATL & WTL (to write Windows applications), and code generation.
 
Pablo was born in 1963, got married in 1998, and is the proud father of two wonderful girls.
 
Favorite quotes:
"Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, "The Devil's Dictionary", published in several newspapers between 1881 and 1906).
"You are to act in the light of experience as guided by intelligence" (Rex Stout, "In the Best Families", 1950).
Member since Tuesday, March 25, 2003 (11 years, 6 months)
  • 18 Oct 2013: Best C++ article of September 2013

Contributions

Articles 7 (Legend)
Tech Blogs 0
Messages 248 (Regular)
Q&A Questions 0
Q&A Answers 165
Tips/Tricks 2
Comments 131

Links

Reputation

For more information on Reputation please see the FAQ.

Privileges

Members need to achieve at least one of the given member levels in the given reputation categories in order to perform a given action. For example, to store personal files in your account area you will need to achieve Platinum level in either the Author or Authority category. The "If Owner" column means that owners of an item automatically have the privilege, and the given member types also gain the privilege regardless of their reputation level.

ActionAuthorAuthorityDebatorEditorEnquirerOrganiserParticipantIf OwnerMember Types
Have no restrictions on voting frequencysilversilversilversilverAdmin
Store personal files in your account areaplatinumplatinumSitebuilder, Subeditor, Supporter, Editor, Staff
Have live hyperlinks in your biographybronzebronzebronzebronzebronzebronzesilverSubeditor, Protector, Editor, Staff, Admin
Edit a Question in Q&AsilversilversilversilverYesSubeditor, Protector, Editor, Admin
Edit an Answer in Q&AsilversilversilversilverYesSubeditor, Protector, Editor, Admin
Delete a Question in Q&AYesSubeditor, Protector, Editor, Admin
Delete an Answer in Q&AYesSubeditor, Protector, Editor, Admin
Report an ArticlesilversilversilversilverSubeditor, Mentor, Protector, Editor, Staff, Admin
Approve/Disapprove a pending ArticlegoldgoldgoldgoldSubeditor, Mentor, Protector, Editor, Staff, Admin
Edit other members' articlesSubeditor, Protector, Editor, Admin
Create an article without requiring moderationplatinumSubeditor, Mentor, Protector, Editor, Staff, Admin
Report a forum messagesilversilverbronzeProtector, Editor, Admin
Create a new tagsilversilversilversilverAdmin
Modify a tagsilversilversilversilverAdmin

Actions with a green tick can be performed by this member.


 
GeneralOn global pointers. [modified] PinmemberPablo Aliskevicius4-Apr-12 19:42 
GeneralThe programmer as an artist PinmemberPablo Aliskevicius12-Sep-11 23:09 
GeneralRe: The programmer as an artist PinmemberAniruddha Loya14-Nov-11 21:29 
GeneralThere is no such thing as quick and dirty. PinmemberPablo Aliskevicius30-Mar-09 21:30 
GeneralRe: There is no such thing as quick and dirty. Pinmember ThatsAlok 18-Jul-11 22:57 
GeneralRe: There is no such thing as quick and dirty. PinmemberPablo Aliskevicius19-Jul-11 2:39 
GeneralRe: There is no such thing as quick and dirty. Pinmember ThatsAlok 20-Jul-11 1:07 
GeneralShame on me: a race condition.... PinmemberPablo Aliskevicius28-May-08 8:39 
GeneralWhen multithreading is not an option... PinmemberPablo Aliskevicius19-Mar-07 10:18 
GeneralMore on thread procedures... PinmemberPablo Aliskevicius13-Oct-06 3:36 
General::PostThreadMessage. PinmemberPablo Aliskevicius11-Oct-06 8:05 
Multi threading is anything but boring.
 
A few days ago, I was asked to improve the performance of a program, which reads a FOX Pro table, generates SQL INSERT commands, and executes them against a database.
 
The way to do it was clear: read in one thread, write on another. To spice things up, since inserting is much slower than reading (all that index updates, you know), three writer threads were matched to the reader.
The writers' thread procedure looked like this (pseudo-code):
 

DWORD WINAPI ThreadProc(LPVOID pX)
{
    // Cast passed pointer to what it really is.
    // Initialize COM
    // Generate message pump
    ::PeekMessage(whatever);
    // Connect to database
    while (!done)
    {
        ::GetMessage(....)
        switch(msg.uMsg)
        {
            case WM_COMMAND: // Cast LPARAM to pointer to a Job, execute that job.
            break;
            case WM_QUIT:
            done = true;
            break;
 
        }
    }
    SetEvent(reallyDone);
    return 0;
}

 
Nice, right?
Tested it with 16K records: runs like the wind, results are fine.
64K records: still OK.
80K records: some start to get lost.
 
I've use ::PostThreadMessage() for quite some time: the caller allocates a Job, posts it to the queue, the worker thread pops it from the queue, executes it, and deletes it. All synchronization tasks are taken care of by the OS, which minimizes thread switches.
 
Well, you always have to read the fine print. And the fine print for ::PostThreadMessage() is that the queue size is 10,000 messages. That's a lot, if you have a few dozen long-running jobs (in the past, for me, that was the usual).
 
So, how could I handle it?
 
My first idea was the use of a 'thermostat'. An integer was interlock-incremented whenever a message was posted, and interlock-decremented whenever a job was executed, thus holding the count of messages in the queue.
 
The manager thread would test the queue size: if longer than 900 messages, it would Sleep for 50 milliseconds: if, after that, there were less than 1000 messages, it would try to post one (in a loop); if, after 5 tries the message was not posted yet, the job would be executed on the calling thread.
 
I didn't like it: whole lot of interlocking going on, and Sleep is by far not my favorite API.
 
Well, the bad news was as expected: performance went down by 30%, but still it was three times faster than the original program.
The good news: 80K records, and none got lost. 150K, and none got lost!
 
So I tried for 400K (the program should be able to send about a million): well, it got stuck after 215K. Playing with the thermostat settings helped a bit, but no cigar.
 
After a couple of hours, I gave up. Added std::queue to the mix, managed synchronization with a critical section (which protected this queue), and performance went back to good. Private bytes and CPU usage were totally flat, up to 400K records.
 
The program was ripe for the QA department.
 
What did I learn?
 
::PostThreadMessage() is a nice tool, but it has some limitations. Its usage: when you have just a few 'big' jobs, and in a program which runs, does its thing and exits. For long-running programs, or programs which send to the worker threads a lot of small jobs, you're better off rolling your own queue.
 
And yet, multithreading, when you know how to do it, can be a great way to make an impression, and to become the star of your company parties.
 

 
Pablo

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.


Advertise | Privacy | Mobile
Web04 | 2.8.140926.1 | Last Updated 1 Oct 2014
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid