You can enforce row level lock while selecting from a table, instead of table level lock. Use "LOCKING ROW FOR ACCESS select * from table_name ......... ". In Teradata, locking is by default table level. So, even a simple select query will lock the entire table. Always lock the table row level while selecting.
Upendra's answer only gave part of the picture. When inserting or updating rows from a query (Insert/ Select or Update where the primary index is not specified), a Write lock is placed on the table. If you Insert Values or Update where PIVal = 12345 (via SQL or Multiload) then a Write lock is placed at the row level.
If you do a select without specifying the PI values, a Read lock is placed at table level. A Read Lock will not read through an existing write lock (and vice versa) so the one who gets in second will be delayed or bounced if NOWAIT is specified. If you put a LOCKING ROW (or Tablename) FOR ACCESS on the Select query, the Select will read through any Write lock at row or table level. (So-called "Dirty Read".) This only applies to Select - a Write lock cannot be downgraded to an Access Lock. This is why most sites only allow read access through Views - they put the LOCING FOR ACCESS clause in the views.
So yu can either go to this method, or do the Insert or Update by Multiload - extract a file of what you want to update and feed it back. (Not as silly as it sounds for very high data availability systems.)
If User1 and User2 do not have the NOWAIT option set, the inserts will run consecutively. First one to send the statement gets in first; the second waits until the other user completes. You cannot downgrade a Write lock, so they cannot run concurrently.