No, it wouldn't. All you need to store this kind of data is a simple file. Most people would probably use PHP for something like that due to its ubiquity, but it could even be a few lines of bash, or Python, or Go, or whatever...
You mostly likely need a WAL Mode SQLite database. Most of the time, it's way simpler that handling state handling in concurrent situations yourself. (also, bindings are often available - if not outright bundled by default - under most common languages)
The "easy" way is all fun and games until your file is accessed in a concurrent fashion, and then your options are:
a) flat out die when concurrent things happens (file locks; default sqlite3 behaviour);
b) just write blindly to file and pretend concurrecy doesn't exist, but randomly lose data - (write to files directly like a crazy person; sqlite3 PRAGMA schema.synchronous = OFF)
c) allow reading at anytime, but serialize writing somehow (file locks + write + move atomic file operations; append writing and a journal; sqlite3 PRAGMA journal_mode=WAL)
Or redis.
Overkill, If you are writing to the text file only to increment a number of visitors, none of what you mentioned above is even required.
Create a "counter-hit" file for each visitor, count the number of files in the resources directory. Populate the master file with the file count and delete all the temporary files. Configure it on a crontab for say every three seconds.
Online now was even easier. IFrame refresh within the homepage. Upon refresh, populate the file with something like "online=true". Read the file every X, if the file modifcation hasn't been refreshed within 30 seconds, nerf the text file and mark that user as offline. psuedo-dynamic, but times were different then. I coded these in perl back in the day for my RTCW clan and how I miss it much.
Being a webmaster was art, an art that's now lost..
If the page isn't resident in the page cache, the thread(s) executing the atomic increment will take a page fault and be blocked until the file data is read from storage. The latency of the fault might be significant, but the counter will remain accurate.
There's an important caveat I should have added: the counter file might be very stale after a power failure. If you care about the counter integrity, you have to msync(MS_SYNC) periodically, and that's expensive. It might actually stall all threads interacting with the page, depending on the filesystem; that used to be true but I'm not certain it still is (see https://lwn.net/Articles/486311/). Where writeback is allowed to race with writes, whether you would be guaranteed the 8-byte value written back wasn't "torn" without explicitly blocking increments while syncing is also an interesting question if DMA is involved...
For a view counter - yes, you can use a full blown database to concurrently increment a simple integer value; or, you could do it in a few lines of code by yourself too.
$ redis-cli INCR hit-count
If you know that you'll need a cannon anyway, then sure, go for it, but when all we deal with are flies there's no reason to go that far. You could easily set up this kind of website on servers so simple that getting redis running on them would inflate their complexity quite considerably.
This is likely what was done. Nobody really cares if a hit counter on a web page loses a few updates.
Linux got proper POSIX thread support with NPTL only in 2002.
Of course you have to make sure to not run out of diskspace or max file size of the OS/filesystem (2GB on a 32bit system?)